Open Bug 1681825 Opened 3 years ago Updated 3 years ago

Efficient low frequency animations


(Core :: DOM: Animation, enhancement)






(Reporter: jaffathecake, Unassigned)


(Keywords: perf)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

I did some research on how efficient browsers are at animations where not-a-lot happens.

I played with the above while monitoring the task manager.

The "High frequency animation" shows how much CPU is used on a 60hz (or whatever display frequency) animation.

"setTimeout" shows how much CPU is used for a setTimeout-driven animation that updates every 5 seconds. This uses almost no CPU.

The rest are CSS/web animations that update infrequently.

It seems like Firefox uses way too much CPU on these types of animation. Chrome has similar issues ( Safari does really well.

Low frequency animations are useful for things like blinking cursors. Developers shouldn't have to fallback to setTimeout for efficiency here.

Also, if browsers were efficient here, empty animations with the web animation API could be used as an alternative to setTimeout/Interval, with the benefit of pausing while the tab is hidden, and having a more consistent timing model.

This could use a profile if someone has time.

I know we used to compare the progress values generated during sampling to ensure we didn't trigger unnecessary style updates when using step functions.

I had a quick look at the test case, just comparing the color animations (since they run on the main thread and are easier to compare). The "Animation steps" one is clearly doing style updates when it doesn't need to so perhaps we regressed that optimization.

I'm not sure about the "Animation keyframe steps" one.

The keyframes are:

      @keyframes to-red-step {
        from { animation-timing-function: steps(2); }
        to { background: red; }

but we seem not to apply the timing function to the implicit from value. I think that might actually be correct per spec since you can have multiple from keyframes so which one should you take the animation-timing-function from?

So, if my recollection of the spec is correct, that particular test might be bogus.

The other ones, "discrete values" and "mostly same values" are a bit more tricky. We might not be able to optimize out doing style updates easily for those. Beyond that I'm not sure if we would expect a noticeable difference in CPU usage for those, particularly when using WebRender.

Keywords: perf
You need to log in before you can comment on or make changes to this bug.