http://m8y.org/tmp/testcase429.xhtml http://m8y.org/tmp/testcase430.xhtml These pages just alter the background position of a couple of linear gradients. In Safari 8, machine is silent even if left running for hours. In Firefox, CPU fan spins to maximum life after like 30 seconds.

That's a nice testcase. I suggest we add a GradientLayer implementation (or add gradient capabilities to ColorLayer), and then for nsDisplayBackgroundImage, if the background-image is a gradient, and the properties background-image, background-position or background-size are animated, we make its layer state LAYER_ACTIVE and create a GradientLayer for it.

Do we even need a GradientLayer for this? I think we just need code to treat background-position as an animated geometry root, and then we'd get a PaintedLayer for the background which would be sufficient. We'd need a GradientLayer for dynamic background-size changes though, which would be awesome to support.

Oh, I didn't actually read the testcase correctly. I thought it was manipulating gradient stops. But it's easy to write one that does, and then we'll need a GradientLayer. :-) (In reply to Matt Woodrow (:mattwoodrow) from comment #3) > I think we just need code to treat background-position as an animated > geometry root, and then we'd get a PaintedLayer for the background which > would be sufficient. Assuming the animated background-position value is layer-pixel aligned. Otherwise we'll end up with the same dilemma as with position:absolute (bug 1009693).

> That's a nice testcase. Thanks. > Oh, I didn't actually read the testcase correctly. I thought it was manipulating gradient stops. > But it's easy to write one that does, and then we'll need a GradientLayer. :-) Reason I didn't manipulate a linear gradient is that transitions and keyframes cannot, at present do much of anything to background-image lists or gradients in them, and I wanted a pure CSS demo. The idea was that this should be easier for browsers to optimise than similar JS demos which, when tested on various browsers did indeed suck up a ton of CPU updating gradients like 20 times per second. Since this one only moved a couple of textures around, I was hoping it would be done mostly on the GPU, which seemed the case, well, sometimes ☺

Ehm... that could have been more clearly stated as: "manipulating gradient stops cannot be done without javascript right now"

FWIW, bz confirmed last week on his OSX machine that Chrome was also using a ton of CPU across multiple cores. So this appears to only be efficiently rendered in Safari. Hm. I guess I could try Chrome vs Firefox on my Nexus 5...

Welp, FWIW, Chrome is clearly no more efficient on my Nexus 5. After 10 minutes, Firefox went from 100% → 96% on the battery. Chrome went from 100% → 94% System reported 67% Firefox, 20% screen in battery usage vs 71% Chrome, 15% screen. So. This is definitely just Safari being the clever one.

So. FWIW, Firefox on my Linux machine seems much better behaved. ankh confirms same for him. So maybe Firefox' problems are OSX specific. gfx.canvas.azure.backends;skia on both Linux and OSX.

It's specific to OS X in the sense that OS X is one of the platform where Firefox doesn't use accelerated content rendering. Linux using xrender has accelerated content rendering. gfx.canvas.azure.backends is unrelated because the test page doesn't use canvas.

My bad. Not sure what I was thinking. I meant to check gfx.content.azure.backends and for some reason instead of searching on azure, searched on "skia" and my eyes skimmed over the variable name. Was using cg on OSX and cairo on linux. And, 'k. Thought this was something specific about accelerating background layers. Admittedly the Firefox CPU usage on Linux is still kinda high. 10% X11, 30% Firefox

Nice person on #blink linked me to: http://code.google.com/p/chromium/issues/detail?id=507015 Which seems to be the analog of this. (Safari fast, Chrome slow).

BTW, I don't know what you guys did under Linux but CPU usage is now way better. like. 20% combined Xorg/Firefox in nightlies instead of a combined 40-50% of a core in stable. By contrast Chrome is basically maxing out a core (besides having the ugly banding due to that skia bug) I retested OSX on nightly to see if things had improved there, but there was no change.

Update on linux side of things. CPU usage is now as bad as chrome due to having switched to skia by default in nightlies. Also the ugly banding that skia does is still there, even though a patch was made for that like a year ago.

I'm not seeing this with 89 beta on Macbook pro big sur