846128 - SimileTimeline extremely slow in firefox

Status: RESOLVED INCOMPLETE

(Core :: Web Painting, defect)

Description

[Honza Bambas (:mayhemer)]

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?

Comment 1

[Honza Bambas (:mayhemer)]

Same when comparing on an old and slow imac using Safari - perfectly fluent.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Honza Bambas (:mayhemer)]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, I haven't done it yet. Why do you you think we need throttling, not just anti-flooding?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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...

Comment 7

[Honza Bambas (:mayhemer)]

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.

Comment 8

[Honza Bambas (:mayhemer)]

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.

Comment 9

[Honza Bambas (:mayhemer)]

So, any news here?

Comment 10

[Alin Ilea, Desktop QA]

Marking this as Resolved > Incomplete since the last activity on this issue was 9 years ago, the link provided in the description doesn't work and it might not be relevant anymore since there are no new updates here. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.