Open Bug 1503259 Opened 6 years ago Updated 17 days ago

Animated page load throbber causes a permanent ~9% CPU load for Renderer threads of the main process

Categories

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

Product:
Core
Component:
Graphics: WebRender
Version:
64 Branch
Type:
defect

Tracking

()

Status:
REOPENED
Project Flags:
Performance Impact medium

People

(Reporter: whimboo, Unassigned, NeedInfo)

References

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

Details

(Keywords: perf:resource-use, power) 

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:65.0) Gecko/20100101 Firefox/65.0 ID:20181030100414

Today I had to use my tethered mobile phone to load some Bugzilla pages. Due to a bad mobile signal I only had a GPRS connection. As such loading the pages caused Firefox to take as nearly 100% of CPU and let the fans spin-up in my MacBook. This went as long as the page finished loading, or I manually stopped the load process. 

Doing that for a couple of tabs, and over a period of time will drastically drain the battery.

Actually this problem can clearly be reproduced but only with WebRender being enabled. Once it has been turned off, CPU load falls back to 20 - 40%.

I assume that some animation - maybe the load throbber? - is causing that?
We should check if this is an issue across all platforms.
Blocks: stage-wr-trains
Priority: -- → P4

Does this still happen for you?

Flags: needinfo?(hskupin)

Closing for now. Please reopen if it still happens.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE

Sorry, I was a bit away the last weeks. But yes, it still happens and I have seen it recently. Here some steps to reproduce the problem:

  1. Connect to a local WIFI
  2. Move far away so the connection is poor (I cannot repro via throttling in devtools)
  3. Try to connect to any page

Inspect the CPU usage right away. Especially while Firefox is trying to lookup for the domain the CPU usage is kinda high.

I could try to create a gecko profile maybe later today or the next days, which might be more helpful.

Status: RESOLVED → REOPENED
Flags: needinfo?(hskupin)
Resolution: INCOMPLETE → ---

Not sure if this is only webrender related or not. I just got a high CPU usage of about 90% for a while, and profiled it here:

https://perfht.ml/2EjAG3o

It seems to be related to CompositorBridgeParent::CompositeToTarget.

I will try if I can get a profile from a webrender enabled build too in the next days. But maybe the above profile already helps a bit. Mike, maybe this is something you are interested in?

Flags: needinfo?(mconley)

Is something animating when you're in this state?

Flags: needinfo?(mconley)
Whiteboard: [qf]

In the current tab? There is only the loading throbber in the tab. That's all.

Whiteboard: [qf] → [qf:p3:resource]

It looks like that profile has WebRender off. Moving to non-WebRender unless there's something that only shows up with WebRender on.

Component: Graphics: WebRender → Graphics
Priority: P4 → P3
No longer blocks: stage-wr-trains

Maybe this is throbber related and the recent patches from Markus Stange should have made it way better. I cannot test right now, but will do it later this week.

Flags: needinfo?(hskupin)

I wasn't able to see / reproduce it within the last year. So I think that closing the bug as WFM based on the changes from Markus (sorry I don't have a bug number) is the right action here.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 4 years ago
Flags: needinfo?(hskupin)
Resolution: --- → WORKSFORME

So this problem is actually not related to a slow network but the page load throbber as shown beside the tab's title as long as the page is loading. In detail with a recent Nightly build (and WebRender enabled) this takes ~9% CPU load. Hereby the two threads with the names Renderer and WRRendererBackend take most of the CPU time.

Here the recorded profile of a slow loading page: https://share.firefox.dev/3ajh5iL

Jeff, is this also related to CoreAnimation (similar to bug 1689453)? But given that this extra CPU load is happening for each and every navigation it's more important.

Blocks: power-usage
Status: RESOLVED → REOPENED
Component: Graphics → Graphics: WebRender
Resolution: WORKSFORME → ---
Summary: High CPU load when loading web pages through slow network connections → Animated page load throbber causes a permanent ~9% CPU load for Renderer threads of the main process
Whiteboard: [qf:p3:resource] → [qf]
Flags: needinfo?(jmuizelaar)

Markus, after you filed all the power related WebRender bugs yesterday I had another look at the profile from my last comment. As it looks like it's not related to any of those newly filed bugs. There is on Runnable that is visible over and over again, which is mozilla::wr::RenderThread::HandleFrameOneDoc. Actually I have seen the same Runnable already on bug 1689453, so maybe both bugs are related?

Flags: needinfo?(jmuizelaar) → needinfo?(mstange.moz)

That runnable just means that we're rendering a new frame. It's where we tell the GPU what to draw. It is expected to appear at 60Hz if you have an animation running.
It would be great to get a breakdown of CPU usage per thread comparing non-WR and WR.
You can use http://tests.themasta.com/load-never-finishes.php to get a long-running spinner.

Flags: needinfo?(mstange.moz)

Whimboo, do you think you can provide what Markus asked?

Flags: needinfo?(hskupin)

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

It would be great to get a breakdown of CPU usage per thread comparing non-WR and WR.

Do you want to have each and every thread included or just the rendering threads means the graphics preset of the profiler?

You can use http://tests.themasta.com/load-never-finishes.php to get a long-running spinner.

Oh great. Good to know there is such a page.

Flags: needinfo?(hskupin) → needinfo?(mstange.moz)

Actually I was just looking for %CPU numbers, per thread. But it seems like there is no good tool to get those numbers.
Anyway, I did some profiling and it looks like bug 1690621 is the biggest problem here. Once that's fixed we can gather some more numbers.

Flags: needinfo?(mstange.moz)

Sounds good. Thanks for the information.

Depends on: 1690621
Whiteboard: [qf] → [qf:p2:resources]

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

Actually I was just looking for %CPU numbers, per thread. But it seems like there is no good tool to get those numbers.

You can use about:processes with the preference toolkit.aboutProcesses.showThreads set to true, or my PerfChaser extension.

Anyway, I did some profiling and it looks like bug 1690621 is the biggest problem here. Once that's fixed we can gather some more numbers.

I'm afraid to say but nothing changes here. As far as I can see the numbers haven't even changed.

Here another profile with your test page, and where I paused the animation of the throbber for a while:
https://share.firefox.dev/3kfLDGs

Flags: needinfo?(mstange.moz)

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

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

Actually I was just looking for %CPU numbers, per thread. But it seems like there is no good tool to get those numbers.

You can use about:processes with the preference toolkit.aboutProcesses.showThreads set to true, or my PerfChaser extension.

Could you post the numbers you get with that here on the bug, both with non-WebRender and with WebRender? Only for the top 5 or so threads.

Flags: needinfo?(mstange.moz) → needinfo?(hskupin)

Sorry for the delay but I somehow missed the needinfo request, and even Bugzilla didn't remind me. Here the requested numbers for all the threads that consume >=1% of CPU on the main thread:

With WebRender:
---------------
Main Thread         7%
Renderer            4%
WRRenderBackend     3%
Compositor          1%
CVDisplayLink       1%

Without WebRender:
------------------
Main Thread         8%
Compositor          7%
CVDisplayLink       1%

Markus, does that help?

Flags: needinfo?(hskupin) → needinfo?(mstange.moz)
Flags: needinfo?(mstange.moz) → needinfo?(jmuizelaar)
Whiteboard: [qf:p2:resources] → [qf:p2:resource]
Flags: needinfo?(jmuizelaar)

Re-adding needinfo for Jeff in case he could help here.

Flags: needinfo?(jmuizelaar)

If this is about tab animation then check also this bug 1731590.

QA Whiteboard: qa-not-actionable

I'm not sure how easy it is going to be to get the CPU usage a lot lower. If we were able to have the throbber run entirely with a coreanimation animation that would probably make a big difference, but it might be quite a bit of work to get that hooked up.

To get a feeling for the possible benefit of this can you compare the power usage of a spinning throbber in Firefox, Chrome and Safari with Intel Power Gadget and report the results here?

Flags: needinfo?(jmuizelaar) → needinfo?(hskupin)
Performance Impact: --- → P2
Keywords: perf:resource-use
Whiteboard: [qf:p2:resource]

I just tried the http://tests.themasta.com/load-never-finishes.php page and the numbers I'm seeing in about:processes match pretty well what Henrik reported in comment 21 for the "with webrender" case.

Here's a profile of it: https://share.firefox.dev/3rcXfyT Is there anything that looks like it could be optimized here?

Then I wondered if we stop running the animation when the loading tab is scrolled away in the tab bar. Here is a profile of me opening many new tabs until the permanently loading tab scrolls away: https://share.firefox.dev/3uvkJkN
I see we keep having MozAfterPaint events sent to the parent process main thread and the Compositor track has many "EmptyTransaction" markers (but the SampleAnimation markers stop when the animated element is off screen). Is this expected or should we avoid some of this work?

I wonder if there are also things that should be done on the front-end: should the animation be stopped after some time (maybe a minute or two?) and replaced with a still icon? Should the front-end attempt to detect the scrolled-away tabs and have a CSS rule to stop entirely the animation on them?

Flags: needinfo?(mstange.moz)
Flags: needinfo?(jmuizelaar)

I totally missed my needinfo. So thanks a lot Florian for checking that.

Flags: needinfo?(hskupin)

I'll let Jeff answer these questions.

Flags: needinfo?(mstange.moz)
Flags: needinfo?(jmuizelaar)

Jeff if you find the time it would be great to get Florian's questions from comment 26 answered.

Also cc'ing Emilio in case we can do something for layout.

Flags: needinfo?(jmuizelaar)
Severity: major → S3

Note that there are quite a few cases when loading Google doc related pages when the load indicator never stops unless you manually hit the stop button. Not sure what's going on in these cases (which might indeed be worth a different bug) but it raises a problem with exactly this bug given that the CPU load is always ~9% higher for each of these tabs.

Today the battery of my MacBook drained a lot until I noticed that a tab that never ended loading a Google slide was causing 40% CPU load on the main process for several hours.

Markus, given that Jeff didn't answer the question do you think that this issue is worth re-triaging?

Flags: needinfo?(mstange.moz)

I did a quick comparison of Chrome, Safari and Firefox on macOS.

Safari just uses a progress bar that doesn't move on http://tests.themasta.com/load-never-finishes.php so it doesn't have a problem.

Chrome has two processes using 7 and 6 percent cpu respectively, and windowserver using 15.

Firefox has one process using 10 percent cpu and window server using 15.

(In reply to Timothy Nikkel (:tnikkel) from comment #32)

Chrome has two processes using 7 and 6 percent cpu respectively, and windowserver using 15.

Firefox has one process using 10 percent cpu and window server using 15.

Please note that those numbers need to be multiplied by the open tabs that show the load throbber. Having eg. a couple of tabs open that never finish loading (I have this still a lot for Google doc pages) the CPU load easily reaches more than 50%.

A visible animation is going to cause some cpu to be used, so perhaps an investigation from the front end side could be begun in parallel?

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

Having eg. a couple of tabs open that never finish loading (I have this still a lot for Google doc pages)

You filed a separate bug for this, right? Can you link it?

Flags: needinfo?(hskupin)
Depends on: 1812019

(In reply to Timothy Nikkel (:tnikkel) from comment #34)

A visible animation is going to cause some cpu to be used, so perhaps an investigation from the front end side could be begun in parallel?

(In reply to Florian Quèze [:florian] from comment #26)

I wonder if there are also things that should be done on the front-end: should the animation be stopped after some time (maybe a minute or two?) and replaced with a still icon?

I filed bug 1812019 to cover the front-end work. Let's keep this bug for the platform work. Especially figuring out if the animation could be stopped automatically when it is scrolled out of view.

Should the front-end attempt to detect the scrolled-away tabs and have a CSS rule to stop entirely the animation on them?

Answering my own question after talking with Timothy: Probably not without investigating first if it's possible to do it on the platform side first.

(In reply to :Gijs (he/him) from comment #35)

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

Having eg. a couple of tabs open that never finish loading (I have this still a lot for Google doc pages)

You filed a separate bug for this, right? Can you link it?

Not yet given that I don't have steps to actually reproduce this issue. At least today I noticed that https://blog.google/products/chrome/new-chrome-features-to-save-battery-and-make-browsing-smoother/ seems to always show it to me. But at the end it might be a problem in combination with NoScript given that making changes back and forth makes it working. I'll try to get more details over the next days and will file a bug once I have reproducible steps.

(In reply to :Gijs (he/him) from comment #35)

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

Having eg. a couple of tabs open that never finish loading (I have this still a lot for Google doc pages)

You filed a separate bug for this, right? Can you link it?

As turned out today the problem was actually related to the NoScript extension. In its settings both font and script were not allowed for gstatic.com. While being on Google doc specific sites this might be a deal breaker for some features not working, but loading random pages which have eg. embedded Google fonts and initially never finish loading is weird. I'll run with NoScript disabled for a while now to see if that assumption is 100% accurate.

Flags: needinfo?(hskupin)

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

(In reply to :Gijs (he/him) from comment #35)

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

Having eg. a couple of tabs open that never finish loading (I have this still a lot for Google doc pages)

You filed a separate bug for this, right? Can you link it?

As turned out today the problem was actually related to the NoScript extension. In its settings both font and script were not allowed for gstatic.com. While being on Google doc specific sites this might be a deal breaker for some features not working, but loading random pages which have eg. embedded Google fonts and initially never finish loading is weird. I'll run with NoScript disabled for a while now to see if that assumption is 100% accurate.

Huh. Yeah, unless there's script that is constantly retrying the font loads or something, I would have thought that blocked resources don't lead to the spinner remaining visible.

See Also: → 1814961

I was wrong. The problem is persistent even after removing NoScript. I filed bug 1814961 to get this investigated.

Duplicate of this bug: 604052

I think this is still worth fixing but there are no low-hanging fruit here, as far as I remember.

(In reply to Florian Quèze [:florian] from comment #26)

I see we keep having MozAfterPaint events sent to the parent process main thread and the Compositor track has many "EmptyTransaction" markers (but the SampleAnimation markers stop when the animated element is off screen). Is this expected or should we avoid some of this work?

I'm not sure.

I wonder if there are also things that should be done on the front-end: should the animation be stopped after some time (maybe a minute or two?) and replaced with a still icon? Should the front-end attempt to detect the scrolled-away tabs and have a CSS rule to stop entirely the animation on them?

Could it? Sure. Should it? I can't say whether the pay-off is worth it.

Flags: needinfo?(mstange.moz)

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

I was wrong. The problem is persistent even after removing NoScript. I filed bug 1814961 to get this investigated.

I wanted to note that with the fix on bug 1814961 landed in Nightly by Friday last week I haven't seen this issue anymore for those pages that quite often caused the throbber to not stop running. It means the power usage situation has been very much improved for my use case.

Duplicate of this bug: 976058
You need to log in before you can comment on or make changes to this bug.