Firefox uses much more CPU on a simple gradient + keyframe demo than Safari 8

NEW
Unassigned

Status

()

Core
Graphics: Layers
P3
normal
3 years ago
8 months ago

People

(Reporter: nemo, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86_64
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted], URL)

Attachments

(1 attachment)

2.18 KB, application/xhtml+xml
Details
(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
Created attachment 8595344 [details]
Demo page
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).
(Reporter)

Comment 5

3 years ago
> 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 ☺
(Reporter)

Comment 6

3 years ago
Ehm... that could have been more clearly stated as:
"manipulating gradient stops cannot be done without javascript right now"
(Reporter)

Comment 7

3 years ago
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...
(Reporter)

Comment 8

3 years ago
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.
(Reporter)

Comment 9

3 years ago
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.
(Reporter)

Comment 11

3 years ago
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
Whiteboard: [gfx-noted]
(Reporter)

Comment 12

3 years ago
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).
(Reporter)

Comment 13

3 years ago
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.
(Reporter)

Comment 14

a year ago
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.

Updated

8 months ago
Blocks: 1038800
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.