1810876 - opacity:0 element with CSS compositor runnable animation still consumes CPU

Status: RESOLVED FIXED

(Core :: CSS Transitions and Animations, defect)

Description

[Stefan Breunig]

Attachment: animates-opacity-0.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

1. Open attachment as reproducer
2. Open a CPU monitor (htop or otherwise)

Actual results:

Observe that Firefox uses a lot of CPU to draw an empty page.

I'm assuming this requires that rendering/compositing is done on the CPU and not the GPU. FWIW, I have uploaded a power profile: https://profiler.firefox.com/public/zv8g0qqdjf9vv798ghtdyvvczzn74mtgv9yrxc8/calltree/?globalTrackOrder=0&thread=0&v=8

Expected results:

Firefox uses almost no CPU.

This is the case for hiding the element using "visiblity:hidden" or "display:none". However, the example uses "opacity:0" where seemingly no optimization is applied.

Potentially related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1166500
https://bugzilla.mozilla.org/show_bug.cgi?id=1218169

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Stefan Breunig]

Testing with gfx.webrender.all=true, the CPU usage increase is still present compared to "display:none" and other more optimized paths. Eyeballing it on my machine is <1% CPU usage if no animation or optimized code path, ~9% with webrender and opacity:0, and ~60% with webrender (software) and opacity:0.

Comment 3

[Florian Quèze [:florian]]

Here's a profile on my machine: https://share.firefox.dev/3QPUUVW

This is almost a duplicate of bug 1761752, but the behavior is worse here, as we actually composite. Maybe because the CSS animation animates the transform property that can be animated on the compositor, whereas the testcase in bug 1761752 animated the background-position property.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

If you set opacity: 0 on the container then behavior should be much better. We're hitting this case almost surely. I wonder if this call can be changed to CanOptimizeAwayDueToOpacity, which would catch this... I don't see anything in bug 1427033 which indicates that it's not possible.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1810876 - Throttle animations in opacity: 0 root. r=boris,hiro

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Florian is right. This is a special case that transform and transform-like properties are able to run on the compositor thread. And thank you Emilio!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/384f12d8ad22
Throttle animations in opacity: 0 root. r=hiro

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/384f12d8ad22

Comment 9

[Florian Quèze [:florian]]

Is it expected that we still paint every 200ms? https://share.firefox.dev/3D0DUH4

Comment 10

[Emilio Cobos Álvarez (:emilio)]

That's the time that we throttle the animations that affect the overflow area on the main thread here, so yes.