Why is drawing thumbnails sequentially so slow?

RESOLVED WONTFIX

Status

Firefox Graveyard
Panorama
RESOLVED WONTFIX
7 years ago
2 years ago

People

(Reporter: mitcho, Unassigned)

Tracking

({perf})

unspecified
Future

Details

(Whiteboard: [ux][polish][profiling required])

Attachments

(1 attachment)

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.
(Reporter)

Comment 1

7 years ago
Created attachment 510090 [details]
Slooooowness
(Reporter)

Comment 2

7 years ago
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.
No longer blocks: 627096
Target Milestone: --- → Future

Comment 4

7 years ago
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.
(Reporter)

Comment 5

7 years ago
Sounds good Sean. Something to look forward to for fx.next, then.
Depends on: 617454
Target Milestone: Future → ---
Marking for Fx.next
Target Milestone: --- → Future
As Panorama is being removed down the line from core Firefox, I think we can close this.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.