Open Bug 846128 Opened 8 years ago Updated 2 years ago
Timeline extremely slow in firefox
Reporting as a general issue, since native code and JS code profiling doesn't tell me where the problem exactly is. STR: - go to http://www.janbambas.cz/moz/profiler/?logs/vodafone-long-load-no-keep-alive.txt - grab the timeline anywhere and drag to left or right to move it - scrolling is extremely abrupt Compare to how Chrome behaves with the same URL - perfectly fluent! This is good use case that can be used to find weak places in JS/rendering code. This is a major issue and clearly the timeline rendering can be fluent as Chrome shows. We must do something to make this much much better. What more can I do to try to find the bottleneck?
Same when comparing on an old and slow imac using Safari - perfectly fluent.
I assume you've made sure this script is not doing browser-sniffing like seems to be the vogue today? ;) Assuming that, here's what my profiler says when I drag around a bunch: 52% reflow triggered by scripted offsetHeight gets off an event of some sort. 9% restyling triggered similarly 20% painting off the refresh driver The rest is noise. Note that we fire mouse move events a lot more often than WebKit does, so if each event handler takes too long we could end up starving paints. Have you tried roc's proposed patches to do mouse moves off the refresh driver?
(In reply to Boris Zbarsky (:bz) from comment #2) > I assume you've made sure this script is not doing browser-sniffing like > seems to be the vogue today? ;) Just to say by true "no": overriding user agent to UA of chrome - no change :) > > Assuming that, here's what my profiler says when I drag around a bunch: > > 52% reflow triggered by scripted offsetHeight gets off an event of some sort. > 9% restyling triggered similarly > 20% painting off the refresh driver > > The rest is noise. > > Note that we fire mouse move events a lot more often than WebKit does, so if > each event handler takes too long we could end up starving paints. Have you > tried roc's proposed patches to do mouse moves off the refresh driver? I'll check and report. Can you please direct me to the patches? Can't find it..
Hmm. I thought they were around, but can't find them... roc, was it just discussion so far? Note that for this case we really do want the throttling, not just anti-flooding.
Yes, I haven't done it yet. Why do you you think we need throttling, not just anti-flooding?
Hmm. I guess it depends on exactly what's happening here. If just anti-flooding would end up with us repainting on time, great. Note that I was seeing performance issues here on Mac, not on Windows where we had the flooding issues...
In general, Simile Timeline on few places in time has to restructure the events displayed on screen, this causes a short jank in all browsers (however, in Firefox longer then in Chrome). When you scroll just a little piece back and forth on place in time where this restructure doesn't happen, it's fluent otherwise. In detail: Win (7 x64), fast native machine: Firefox: very abrupt Chrome: very fluent iMac (10.7 x86), old and slow: Firefox: abrupt, but a little bit less then on Win Chrome: very fluent Safari: very fluent Fedora (17 x64), old and slow single core machine, view port via VNC (!), local net, SSH tunneled Firefox: very much abrupt Chrome: very (or say, very reasonably) fluent This really is not Windows specific.
One hint: when I grab the timeline and quickly move mouse in a small range left and right (like shaking), in Firefox the timeline almost doesn't response. When I release the mouse on some other place then I've grabbed the timeline originally then it (subjectively) instantly redraws at the expected position. Tested on all platforms. During the "shaking" CPU user time is at 100%, kernel insignificant (nearly 0%). CPU tested only in Win.
So, any news here?
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.