No, seriously, why? The attachment shows a bajillion (well, 100+) about:blank tabs load up their thumbnails sequentially on Panorama init. You can see when they get actually update-ed as their favicon dogears disappear. This process strikes me as excruciatingly slow... I couldn't even stand to wait long enough to see all of the thumbnails get updated for this screen capture. Logically, either (a) our throttling of _update's is too strict or (b) the actual _update process is somehow very slow. If it turns out canvas' drawWindow is simply very slow, I guess there isn't much we can do about that, but it'd be good to at least make sure that there isn't anything we can do immediately to improve this situation.
It looks like it's indeed (a) that's the limiting factor, i.e. our heartbeat code. At least on my machine, the actual _update code takes an average of 16ms per call, but our heartbeat is every 100ms. The funny thing is, lowering that heartbeat to be every 10ms, for example, actually makes relatively little difference.
Given our 100ms heartbeat, you should be getting 10 new favicons per second. Maybe not blazing fast, but certainly not nearly as slow as what your video shows. I imagine what you're seeing is the browser itself loading all those tabs (which I suppose is a little odd considering they're all about:blank). Seems like something to investigate post Fx4.
Look at the code in _checkHeartbeat: in the latest patch for bug 617454. I implemented a greedier alg for updating as many tabs as it could in a tunable period of time. I can adapt that patch to this bug, since it looks like zoom is looking pretty good now.
Sounds good Sean. Something to look forward to for fx.next, then.
Marking for Fx.next
As Panorama is being removed down the line from core Firefox, I think we can close this.