1449267 - High CPU & GPU load on www.theguardian.co.uk even after bug 1419079 fix

Status: RESOLVED FIXED

(Core :: DOM: Animation, defect, P3)

Description

[Mark]

Attachment: News, sport and opinion from the Guardian's UK edition | The Guardian.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180327105613

Steps to reproduce:

Similar to bug 1419079 which I understand was failure to throttle an off screen CSS animation.

The same site sometimes uses a small circular throbber which does not seem to throttle when offscreen. Even when this throbber is off screen my CPU and GPU work hard. 

I have attached a grab of the current page, you can see the throbber halfway down the page, Sport:Live England v Italy.

I think it's just an animated GIF but Firefox is using ~200% CPU or ~8 W power and ~8 W GPU power whether it is on or off screen, (see bug 1422090 etc etc)

Attached copy of the page

cheers

Comment 1

[Mark]

PS this is on MacOS 10.13.3 on a 2009 Retina MacBook Pro

Comment 2

[Mark]

It's a CSS animation. A circle approx the size of a pencil eraser. It's weirder than I thought:-

CPU is ~50% Firefox + ~20% content when I'm at the top of the page and the animation is NOT visible. That's very high for a static web page?

CPU jumps to ~80% Firefox + 80% content when the animation IS visible.

CPU drops to very low levels when I scroll right to the bottom of the page.


I think throttling is working OK but there are two problems:-

(1) the tiny CSS animation throbber is using way too much CPU when it's visible

(2) something else in the top part of the page is consuming a lot of CPU even though there are no visible animations.

So (1) and (2) combine when the CSS throbber is visible and my Mac melts. When I get to the bottom of the page neither (1) or (2) apply and the CPU load is very low.

Nightly 2018-03-28; Retina MacBook Pro; MacOS 10.13.3

Comment 3

[Adrian Florinescu [:aflorinescu]]

Tested this issue on Retina MacBook Pro late 2013; MacOS 10.13.2  using latest Nightly 2018-04-01 and latest Release 59.0.2. 

For me Firefox and Content CPU usage are topping ~40-60% load. I would say that is rather close to the reported results taking in account that probably my test machine might be a little better than Mark's. It does look slightly better on 59.0.2 than on 61.0a1, but I haven't manage to figure a way to isolate STR and results in order to get a good comparison.

What's interesting to me is that the processor load for Firefox and Content vary, which would be expected for the live version, but I would've expected to see less in the static html. For me it's between 10% and 60% on the attached html and a bit higher on the live version, depending on the section of the page I'm in.

I'm not entirely sure if this issue is a follow-up from bug 1419079 or something else entirely, but it does seem atm the best component to initially triage to.

Comment 4

[Mark]

If I set layers.acceleration.draw-fps to TRUE I can see that Firefox continues to paint at about 50 fps even when the small circular throbber(s) are off screen.

If I delete the throbber(s) using uBlock Origin's "element zapper", Firefox stops painting, it drops to about 1 fps and CPU load of the Firefox processes drops to a few percent.

Therefore I think the small circular thobber(s) do not throttle when offscreen.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Just to confirm, the throbber animation name is 'live-pulse' and it's on a ::before element, right?

Comment 6

[Mark]

I think so but I am not sure, I was struggling to get the developer tools to work. It's the small round throbber the size of a pencil eraser. There is 1 on the html I uploaded. I am not a Web expert!!!

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Thanks!  Yeah, as of today animation inspector in devtools seems to be broken (bug 1450786 and bug 1450526).  So..

Comment 8

[Mark]

I think animation inspector works OK on Firefox Beta. And I think it is live-pulse, an opacity transform repeating around once per second. I don't know how to tell from Animation Inspector if it's throttling or not. Sometimes I see the lightning bolt (compositing?), sometimes not. 

Now I have reached my limit of Web design knowledge!! Good luck.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

As far as I can tell the throbber on the ::before element is properly optimized when the element is out-of-view.

Mark, do you still see high CPU usage on the site?  If so, a profile result would be useful to know what's going on there.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Oh, are you using WebRender?  That might be related to bug 1456389.

Comment 11

[Mark]

WebRender off.

Attachment 1 [details] [diff] above

I think the live-pulse animation always runs even when it is off screen. I see this in the Animation Inspector & I see 60 fps paints when I set layers.acceleration.draw-fps to TRUE. I think live-pulse might throttle when scrolled to the bottom of the screen but I think it runs when scrolled to the top, even if it's not visible.

CPU load follows the pattern in Comment 2 but the levels are lower

20% Nightly + 15% Content at the top of the page and live-pulse is not visible
20%         + 15%         in the middle of the page when live-pulse is visible
drops dramatically at the bottom of the page ~ single digits


profile scrolled to top of page    https://perfht.ml/2s5kVWy
(compositor running continuously?)

profile scrolled to bottom of page   https://perfht.ml/2s9Jh1w
(compositor not running?)

Both WebRender off, Nightly 2018-05-22, MacOS 10.13.4, 1280x800 default resolution, Attachment 1 [details] [diff] from above.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Thanks for detailed information and profiles.

(In reply to Mark from comment #11)
> 20% Nightly + 15% Content at the top of the page and live-pulse is not
> visible
> 20%         + 15%         in the middle of the page when live-pulse is
> visible

I believe in the first case, even if the animation is invisible, the corresponding layer for the animation is considered as visible.  So the animation simply is running on the compositor.  If the corresponding layer is completely out-of-view, the animation doesn't run on the compositor.

Comment 13

[Mark]

OK so it sounds like Firefox is behaving properly, it's poor page design?

But Chrome does something different, Chrome seems to be able to throttle that animation when I am at the top of the page.

run Chrome --disable-mac-overlays  (to turn off Core Animation & get like-for-like comparison)
use Quartz Debug to see MacOS compositor FPS

Chrome settles to near zero FPS when scrolled to top of the page & live-pulse is not visible. It rises to ~30 fps when live-pulse  is visible. It drops back to near zero FPS when I scroll to the bottom & live-pulse is not visible.

And the problem of course is my usual complaint:- GPU load at high scaled resolutions. at 1680x1050 Firefox uses 18 W GPU power whatever part of the page is visible, because the MacOS compositor has to paint the whole window at 60 fps even when the live-pulse throbber is not visible & the visible page is static.

Chrome --disable-mac-overlays uses very little GPU power at 1680x1050 because it doesn't paint when live-pulse is not visible, and even when live-pulse is visible it only uses 3 W GPU (because it only paints at 30 FPS not 60?????? Is that a power saving trick??????)

So basically Firefox on this page gives me jet engine fans at high scaled resolution whatever part of the page I am looking at. Not good.

I don't know if Core Animation will help, I thought with CA only the tile with the throbber would refresh at 60 fps & the GPU load would be low. But now I am concerned that the whole layer will refresh at 60 fps which could be all the visible tiles ie the whole screen & the GPU load will still be high.

Perhaps we should park this bug until Core Animation comes along, maybe the problem will become negligible? Or I can start complaining again :)

gfx.compositor.glcontext.opaque TRUE
MacBookPro11,1 @ 1680x1050, MacOS 10.13.4, full screen browser window, Attachment 1 [details] [diff]

GPU power in Watts
                                          top of page           middle of page          bottom of page
                                     live-pulse not visible   live-pulse visible    live-pulse not visible

Chrome --disable-mac-overlays                  1 W                  2 W                      1 W
Firefox Nightly                               18 W                 18 W                     18 W

So ~2 hour battery life on this page with Firefox vs 5-6 hours with Chrome. Plus jet engine fans.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

(In reply to Mark from comment #13)
> OK so it sounds like Firefox is behaving properly, it's poor page design?

From the perspective animation optimizations, the animation in question works properly.  That's said, when the browser shows the top of the page, the animation is far from visible region, right?  So our viewport handling (or scrolling frame handling) is somehow broken (or could be more smarter).

Comment 15

[Mark]

Yes, the live-pulse throbber is 2-4 screen heights off screen (depending on scaled resolution)

Hmmm, in that case I think Firefox Mac may still have major power consumption problems even after you implement Core Animation.

Chrome (with Core Animation enabled i.e. default mode) and Safari both seem to be able to isolate the tiny live-pulse throbber and only send that tiny portion of the screen to the MacOS compositor @ ~60 fps. I can see this in Quartz Debug -> Flash Screen Updates. If the live-pulse throbber is off screen there are no screen updates. If the live-pulse throbber is on screen only the tiny part of the screen containing it gets updated. IIUC this makes a huge difference to the GPU power consumption because the MacOS compositor only needs to re-composite that tiny part of the screen. And indeed, with Chrome and Safari, when live-pulse is visible the GPU consumes only tiny amounts of power <1 W @ 1680x1050. When live-pulse is not visible the GPU consumes ~ zero watts.

If I understand you correctly, Future Firefox + Core Animation will still send the whole layer to the MacOS compositor which could be a large part of the screen @ 60 fps. And it will do this even if live-pulse is off screen, but part of live-pulse's layer is on screen (or in the viewport??). I think that might negate much of the potential power savings with Core Animation. If live-pulse is tiny, but live-pulse's layer is large, You could see large power consumption similar to today's Firefox.

I think the rule of thumb with portable Retina Macs at high scaled resolutions is GPU power is roughly proportional to the percentage of the screen being updated and the update fps. If a large percentage of the screen is being updated at high fps the GPU load dominates the machine's power consumption and the Mac gets hot/noisy/bad battery life.

Perhaps I misunderstood, but Chrome and Safari seem to use some clever tricks which Firefox doesn't and these tricks seem targeted at minimising screen update area and fps at high scaled resolutions and thus minimising GPU power.

cheers

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Hey Mark, do you still see high GPU or CPU usage on the attachment in comment 0?  I think bug 1471174 and bug 1430884 improved to some extent.

Comment 17

[Mark]

It looks fixed completely for the attachment with WebRender ON and OFF. I only see significant CPU and GPU usage when the throbber is actually visible on screen.

Nightly Mac 63.0a1 (2018-06-27), MacBookPro 11,1, 1440x900

Thanks very much - great job.

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Thanks!