Closed Bug 1454810 Opened 6 years ago Closed 6 years ago

[blob-image] Very high CPU usage on digitalocean.com

Categories

(Core :: Graphics: WebRender, defect, P3)

defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: gerard-majax, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs, )

Details

(Keywords: perf)

STR:
 1. https://www.digitalocean.com/
 2. Scroll to the bottom, there's an animated worldmap

Expected:
 Animation should be smooth

Actual:
 It's killing my system (Ubuntu 17.10, Core i7-8650U, Intel HD Graphics 620)
There's an SVG filter with ID "goo" which has a blur, a color matrix and a blend. If I delete the filter element, things get a little faster but not much; on the WRWorker thread, most of the time is then spent in PopLayer which makes a memcpy. This memcpy seems both unnecessary and slower than necessary; we might be touching too many pixels.
Profile: https://perfht.ml/2H7eKLP
Bad on other platforms?
Priority: -- → P1
I have got something with macOS 10.11 - latest Nightly.

Webrender enabled => main process ~225% / content process ~ 5% => janky animation and janky scrolling in animation area
Webrender disabled => main ~4% / content process ~ 250% =>  janky animation, smooth scrolling	

In comparison:
Safari content process ~125% => janky animation
Opera content process ~325% => smooth animation

Here is another example:
Go to https://stripe.com/au - there are three SVG animations. These animation(s) are running smooth for me, but the CPU of the main "Firefox Nightly" process skyrockets to ~125% with Webrender enabled. Disabling Webrender the main process stays at around 15% - 30% with the tab & page active.

Note:
The content process in both cases is at 80% - 100% until I deleted the CSS animation, then it is more around 25%. I will see if I can find a bug for that, too.
Depends on: 1456932
Please note: I filled a new bug for the stripe example, as Gecko's CPU/GPU usage there is still quite high with Webrender disabled - see bug 1459381
(In reply to Alexandre LISSY :gerard-majax from comment #2)
> Profile: https://perfht.ml/2H7eKLP

Something interesting in this profile: there are 7 WRWorker threads, but only one of them is ever actually doing anything at a given time. Presumably only one core is free for the WRWorker stuff, and so splitting the work across 8 threads doesn't help any. I don't know if this is a common occurrence or specific to Alexandre's setup.
The only thing I changed is the number of process: dom.ipc.processCount is 16
There's only one blob image and it all gets drawn on one thread. We should tile blob images by default which will allow them to be split up for rendering.
Summary: Very high CPU usage on digitalocean.com → [blob-image] Very high CPU usage on digitalocean.com
The high CPU usage here is pretty well understood, and there's not a lot we can do it about it. Demoting to P2 for now.
Priority: P1 → P2
Blocks: stage-wr-trains
No longer blocks: stage-wr-nightly
Jeff thinks this is the original motivation for blob resizing.
Depends on: 1425871
Depends on: 1490123
Priority: P2 → P3
Digital Ocean removed the animated svg that was causing the issue and we have plenty of other animated svg perf bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Blocks: wr-perf
You need to log in before you can comment on or make changes to this bug.