I experience a constant high CPU load off about 60 - 80% on https://www.megamarsch.de/dresden, which seems to come all from the Compositor thread and might be OpenGL related - at least that is what I get from the recorded profile. But better have a look yourself:

http://bit.ly/2Tc5rj0

Interestingly the CPU load drops when I stop allowing scripts from jimstatic.com via noscript.

Mike maybe you could have a look?

I can not reproduce a high cpu load (got 1,5%) on that page with the latest Firefox67 nightly and Firefox65 on windows.

This might be MacOS specific.

I'm not sure if I'm able to reproduce it or not. On a 2015 Macbook, I'm seeing 20-30% CPU usage.

For some reason the profile you linked is missing the web content processes, so it's hard to see what's triggering the excessive compositing. Could you try and record a profile again?

Even if it causes lesser CPU load having 20-30% when doing nothing on that page is way too much. Both Safari and Chrome having nearly no CPU load. When I tried it again now, I can also no longer see that very high usage.

Note that the content processes are part of this profile! But those aren't visible, because they are hidden by default due to inactivity. Open the context menu over the parent process box on the left side, and select the wanted web content processes.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #4)

I tried it again now, I can also no longer see that very high usage.

Are you refering to no longer seeing the high usage with Chrome/Safari or with Firefox?

about:performance actually shows me that the high cpu load while having the page open comes from a sub frame with the location www.youtube-nocookie.com. It actually embeds the following content:

<iframe id="cc-m-video-container-6953383662" class="cc-m-video-container" src="https://www.youtube-nocookie.com/embed/7StAKPuRCzE?wmode=transparent&amp;vq=hd1080" allowfullscreen="true" frameborder="0">
</iframe>

So it seems to be the video, or the embedded player, which seem to be causing this high cpu load here. Opening the video in its own tab doesn't show any spikes in cpu load.

Sorry, the above is a red herring. The actual problem here is the invisible loading spinner located below the basket overlay on the right side:

<span class="j-cart-loading-spinner icon-web-loading-spinner"></span>

When I remove this particular node, the CPU load goes down to normal. Why do we try to render this animation when it is even not visible?

Is this graphics or layout related?

From the profile (which does include web content), it's the process 4/8 which I can see has some animation code running.

It seems it's an animation that we don't manage to throttle, even though the icon is not visible since it has opacity: 0.

The animation in effect is @keyframes spinit{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}, so it sounds to me we should be optimizing this...

Hiro, I don't see any opacity check around here in the animation throttling code, should there be one?

I'm surprised not to see it, but maybe I'm missing some other checks somewhere else?

Indeed, with this test-case: data:text/html,<style>@keyframes spin { from { transform: rotate(0); } to { transform: rotate(360deg) } } div { opacity: 0; animation: spin 1s linear infinite; width: 100px; height: 100px; background: red; }</style><div></div>

I can see continuous paints. That seems unfortunate, and in the general case it may be hard to detect whether we're invisible due to an opacity: 0 ancestor, but for this trivial case at the very least it should work.

ni? hiro to confirm that I'm not missing anything there. Me or he can probably fix it.

But I agree this is probably the animations code not throttling an animation incorrectly.

Maybe this is way worse on Mac because our compositing story for mac may be different? Maybe the stuff Markus is working on helps here.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

From the profile (which does include web content), it's the process 4/8 which I can see has some animation code running.

It seems it's an animation that we don't manage to throttle, even though the icon is not visible since it has opacity: 0.

The animation in effect is @keyframes spinit{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}, so it sounds to me we should be optimizing this...

Hiro, I don't see any opacity check around here in the animation throttling code, should there be one?

That's bug 1427033.

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

That's bug 1427033.

I see, thanks!

We should really fix that...

Even if the animation is not throttled, I'm surprised we trigger composites for this animation. We have two other lines of defenses here which could prevent composites from happening:

• On the main thread, when we create layers for the animation, we have the option not to layers inside opacity:0 subtrees unless there's will-change:opacity. Maybe we deem the subtree necessary for correct hit testing?
• On the compositor thread, when we compute the invalid window region, we have the option to ignore changes within opacity:0 subtrees. However, I don't see any code to handle zero opacity in LayerTreeInvalidation.cpp, so maybe we just need a small tweak here?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

Indeed, with this test-case: data:text/html,<style>@keyframes spin { from { transform: rotate(0); } to { transform: rotate(360deg) } } div { opacity: 0; animation: spin 1s linear infinite; width: 100px; height: 100px; background: red; }</style><div></div>

I can see continuous paints.

Continuous refresh ticks, yes, but not continuous paints and not continuous composites. Whereas Henrik's profile shows continuous composites. (At least based on the sample information... there's a curious lack of markers in that profile.)

Actually, I am unable to reproduce continuous composites on https://www.megamarsch.de/dresden on macOS.

(In reply to Markus Stange [:mstange] from comment #15)

Actually, I am unable to reproduce continuous composites on https://www.megamarsch.de/dresden on macOS.

Please note that this was with an older MBP (i think 2015). Maybe this is somewhat related? Or the code has been changed, and this specific case doesn't happen anymore. To test that you could check with an older Nightly version from that day when I reported the bug. Note, that I also don't see those composites anymore with a recent Nightly.

Should be fixed now I fixed the throttling, mind checking?

Sorry for the delay. Yes, it is fixed. Thanks a lot.