Open Bug 1448926 Opened 3 years ago Updated 2 years ago is slow on nightly compared to Chrome


(Core :: DOM: Core & HTML, defect, P3)

Windows 10




(Reporter: mayankleoboy1, Unassigned)


(Depends on 1 open bug, )


(Keywords: regression, Whiteboard: [gfx-noted])


(1 file)

Attached file aboutsupport.txt
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180325220121

Steps to reproduce:

1. Create fresh profile on nightly
2. Go to

Actual results:

Page will animate
This is slow compared to Chrome

Also try other cases.
Case1: Click on a corner
Case2: Clicl on the rough center
Case3: Click on the rough center to uncheck the boxes.

Expected results:

As fast or faster than chrome

case1:click in a corner:
case2: click in roughly the center:
case3: click on center to uncheck:

Depending on the action/case, I  think that more than one part of nightly show up in profiles. Case1 and Case2 look like gfx. Case3 has quite a bit of Rayon overhead.
ni? for the the third profile:
Flags: needinfo?(emilio)
WR is smoother than non-WR.
But chrome still completes the whole animation faster.
I'll take a look at the site, but if bug 1300659 is involved it probably means the site is using a large number of timers open loop without accounting for how much work is actually occurring.  If that is the case, then it's probably wontfix.
Flags: needinfo?(bkelly)
Component: Graphics → DOM
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Whiteboard: [gfx-noted]
Yea, this site is doing an open loop animation with setTimeout.  See:

This is very similar to the open loop animation I describe in this blog post:

It basically schedules a ton of timers at particular times.  It does not check to see if its falling behind or not.  A better way to do this would be to run a requestAnimationFrame() loop and calculate what elements should be changed on each tick based on the current time.

Note, you can partially disable bug 1300659 by increasing dom.timeout.max_consecutive_callbacks_ms.  The default is to allow setTimeouts to run consecutively up to 4 ms.  If you increase this to something like 1000ms or more, the animation appears to run faster.  Note, however, the frame-per-second drops from a worst case of ~20fps to ~10fps.  So you are trading overall animation time for janking the main thread.

A major goal of bug 1300659 was to avoid one window janking the main thread for other windows in the same process.  So I believe the fix in bug 1300659 is working as intended here.

If we want this animation to run faster as an open loop we need to speed up the painting, etc, done on each modification.  Note chrome runs the animation at full speed and without dropping fps much at all.

I'm moving bug 1300659 to a see also instead of blocking based on the above reasoning.
No longer blocks: 1300659
Flags: needinfo?(bkelly)
See Also: → 1300659
My profile doesn't look like the one from comment 1 at all unfortunately, and we're styling 6 elements according to that, so it seems that somehow the rayon threads took a long time to wake up... Not sure if it's a bug or just a scheduler issue.

About 70% of the time in my profiles is spent drawing checkboxes to a texture to send them  via WR. Not that this is a very representative test-case of any web content, but maybe something could be done there for WR?
Flags: needinfo?(emilio)
(In reply to Emilio Cobos Álvarez [:emilio] from comment #6)

> About 70% of the time in my profiles is spent drawing checkboxes to a
> texture to send them  via WR. Not that this is a very representative
> test-case of any web content, but maybe something could be done there for WR?

My profile was with WR disabled.
As i mentioned, enabling WR does not really improve performance
Here's a profile we gathered with WebRender enabled and changing the checkboxes to blue boxes:
The reason why AddAnimationsForProperty did appear in the profile in comment 8 is that we do inefficiently convert servo's animation value into TransformFunction when we send animations to the compositor and receive the animation on the compositor.  The inefficient stuff will be gone in bug 1457033.
Priority: -- → P3
With the latest nightly, WR, and uBlock disabled:

It is much better now. In fact it is so much better, that a lot of time seems to be spent in Styles.

2019-01-07T23:44:43: INFO :
2019-01-07T23:44:59: INFO : Narrowed inbound regression window from [f1ce520b, 23941690] (3 builds) to [f1ce520b, 996bf60e] (2 builds) (~1 steps left)
2019-01-07T23:44:59: DEBUG : Starting merge handling...
2019-01-07T23:44:59: DEBUG : Using url:
2019-01-07T23:45:01: DEBUG : Found commit message:
Bug 1415987. Use ChooseScale to choose a scale in WebRender. r=jrmuizel

2019-01-07T23:45:01: DEBUG : Did not find a branch, checking all integration branches
2019-01-07T23:45:01: INFO : The bisection is done.
2019-01-07T23:45:01: INFO : Stopped

No idea why, but bug 1415987 massively improves this page with WR enabled.

Depends on: 1415987
Ever confirmed: true
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.