1761752 - Animations in opacity: 0 elements waste CPU

Status: NEW

(Core :: CSS Transitions and Animations, defect)

Description

[Florian Quèze [:florian]]

Attachment: Reduced testcase

I noticed this on https://www.thetrainline.com/book/checkout?lang=fr where I saw RefreshDriverTick markers at 60Hz despite nothing changing on screen: https://share.firefox.dev/3Lme6Xs

As this page is behind a login, I tried to make a reduced testcase. It turned out to be a CSS animation running to move the background position of an element with a css gradient background, but also an opacity of 0.

I'm attaching a reduced testcase, and here's a profile of running the reduced testcase: https://share.firefox.dev/3qGznDg

Changing 'opacity: 0' to 'display: none' stops the animation. 'visibility: hidden' doesn't.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

This is supposed to work: https://searchfox.org/mozilla-central/rev/b671b6390e88672543b9b7c82132be655bd98856/dom/animation/KeyframeEffect.cpp#1381-1389

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Yeah, and keep ticking is for animation events not for styling.

Florian, can you clarify what the problem you are seeing? Note that no animation generates in display:none subtree, it's totally different situations from opacity:0 or visibility:hidden.

Comment 3

[Florian Quèze [:florian]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)

Yeah, and keep ticking is for animation events not for styling.

Could we detect that the document doesn't have any animation event listener, and skip the animation entirely in that case when the opacity is 0?

And even if there are event listeners, could we throttle the refresh driver if a 0 opacity animation is the only thing that keeps it ticking?

Florian, can you clarify what the problem you are seeing?

The problem is that keeping vsync enabled causes a lot of CPU core wake ups. We wake up at 60Hz 3 threads on the parent process (IPDL Background, IPC I/O Parent, CVDisplayLink) and 2 on the content process (MainThread, IPC I/O Child, + BHMgr Monitor on Nightly, but let's ignore this one). Each of these threads seems to use about 0.5% of a CPU core, adding up to a bit less than 3% of a CPU core used continuously.

Here's a profile showing these threads: https://share.firefox.dev/3uC5jdt (except the CVDisplayLink thread which isn't registered with the profiler).

Comment 4

[Hiroyuki Ikezoe (:hiro)]

(In reply to Florian Quèze [:florian] from comment #3)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)

Yeah, and keep ticking is for animation events not for styling.

Could we detect that the document doesn't have any animation event listener, and skip the animation entirely in that case when the opacity is 0?

And even if there are event listeners, could we throttle the refresh driver if a 0 opacity animation is the only thing that keeps it ticking?

Probably both can be feasible, but I am not 100% sure, since our throttling restyles optimization totally relies on current machinery so that there are probably some edge cases we need to unthrottle explicitly or some such.

Comment 5

[Brian Birtles (:birtles)]

We'd also need to not apply the optimization to animations that:

• Have listeners on the finished promise of the Animation
• Have listeners for animation playback events, i.e. Web Animation events, not just CSS animation/transition events
• Affect visibility, opacity, etc.

If we want DevTools to remain up-to-date, we'd also have to disable the optimization when there are animation mutation observers on the document.

(I'd also be a little hesitant about throttling the refresh driver when we have event listeners. It seems reasonable for a Web developer to have an animation set up simply for the purposes of dispatching events, perhaps to synchronize with other animations, for example. It would be frustrating as a Web developer to have to debug why the events are inaccurate in Firefox only, and only when certain properties are applied to an ancestor.)