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 https://lab.hakim.se/checkwave/ 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: https://perfht.ml/2pLImUD case2: click in roughly the center: https://perfht.ml/2pGN5qz case3: click on center to uncheck: https://perfht.ml/2pLJbgb 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: https://perfht.ml/2pLJbgb

WR is smoother than non-WR. But chrome still completes the whole animation faster.

Before landing bug 1300659, it is super fast. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d19cffeae1febc6d669a024340de25228e544475&tochange=24d97dc514d4b8fe608e9aee7527615c1e613606

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.

Yea, this site is doing an open loop animation with setTimeout. See: https://github.com/hakimel/css/blob/7074f2b27518709fe6527376689a3d5466765da2/checkwave/index.html#L63-L78 This is very similar to the open loop animation I describe in this blog post: https://blog.wanderview.com/blog/2017/03/13/firefox-52-settimeout-changes/ 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.

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?

(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: https://perfht.ml/2GXQP0H

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.

With the latest nightly, WR, and uBlock disabled: https://perfht.ml/2FaOYoT It is much better now. In fact it is so much better, that a lot of time seems to be spent in Styles.