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

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.

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.

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.

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.

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!

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

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

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