The default bug view has changed. See this FAQ.

SimileTimeline extremely slow in firefox

NEW
Unassigned

Status

()

Core
Layout: View Rendering
--
major
4 years ago
4 years ago

People

(Reporter: mayhemer, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Updated

4 years ago
Keywords: perf
(Reporter)

Comment 1

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

Comment 3

4 years ago
(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.
Flags: needinfo?(roc)
Yes, I haven't done it yet. Why do you you think we need throttling, not just anti-flooding?
Flags: needinfo?(roc)
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...
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

4 years ago
So, any news here?
You need to log in before you can comment on or make changes to this bug.