zoom responce is delayed when you have a lot of OpenLayer.Layers on the map.

I note that getLegendGraphicUrls is now on the list, which it wasn't before. It was called 64 times, and took an extra second of time. I don't know why this was called so much, or what it's doing, or why this is in the list when it wasn't before, but it isn't in trunk OL, and that makes me suspicious.

getLegendGraphicUrls is in my sandbox on both versions. I'm using an improved version from [1142] I should have used a clean sandbox of trunk for the profile, but I'm seeing the same problem on my modified or the clean trunk too.

Firebug in my browser is apparently not willing to profile at the moment, however, I just did a stopwatch comparison with r6100 and HEAD, and got no measurable difference between the two, with 14 layers added to the lite.html example.

If you can reproduce this, can you attach an example to this page which causes it? The URLs can be bogus, it shouldn't affect things much. If you can attach an example, I'll investigate more.

Okay, now that I got firebug profiling, I can confirm that things are taking longer. Unfortunately, I can't get it profiling against anything other than a singlefile build, so I can't actually get an accurate picture of what's happening -- so this does need more work, but I can't figure out how i can do it. John, if you could attach a profile against a trunk build without any modifications using your firebug profiling Skillz, please do...

So, I've got profiling working again, and I've actually found that I have no significant difference between r5900 and r6200. However, I do see a significant difference in HEAD: specifically, our forcing of a reflow, added for tile transitions, is very much hurting our performance.

John, this means I'm no longer able to replicate your issue... if I ever could, since I'm pretty sure this is the same thing I was seeinig before.

I suggest that we force a reflow *only* when a transitionEffect is in the list of valid transition effects, and *not* otherwise, since it hurts preformacne a lot (specifically, zooming with 25 layers takes 2x as long: 3.1s to 5.9s).

Hm, I'm just noticing that the way we do our check is with a string indexOf: I think this might also not be the best choice, as this call is happening hundreds of times: it's possible cahing this call would also help.

Attaching a patch that is heading in the right directino: when tile transitions are off, there is no obvious ill visual effect, and the result is that zooming in is ~2x faster.

This patch made by cr5 has been moved to a new ticket, #1465. We are moving this ticket to 2.7, when hopefully someone will have time to review it more thoroughly

Mass ticket move out of 2.7 in preparation for a release plan.

If you are actively working on this task, and think that you can help this ticket to get finished and closed by September 1, please move it back to 2.7.