Animated page load throbber causes a permanent ~9% CPU load for Renderer threads of the main process
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
| Performance Impact | medium |
People
(Reporter: whimboo, Unassigned, NeedInfo)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Keywords: perf:resource-use, power)
|
||
Comment 1•7 years ago
|
||
|
||
Comment 3•7 years ago
|
||
Closing for now. Please reopen if it still happens.
|
Reporter | |
Comment 4•7 years ago
|
||
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:
- Connect to a local WIFI
- Move far away so the connection is poor (I cannot repro via throttling in devtools)
- 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.
|
|
Reporter | |
Comment 5•7 years ago
|
||
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:
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?
|
||
Comment 6•7 years ago
|
||
Is something animating when you're in this state?
|
|
Reporter | |
Comment 7•7 years ago
|
||
In the current tab? There is only the loading throbber in the tab. That's all.
|
||
Updated•7 years ago
|
|
|
||
Comment 8•7 years ago
|
||
It looks like that profile has WebRender off. Moving to non-WebRender unless there's something that only shows up with WebRender on.
|
|
||
Updated•7 years ago
|
|
|
Reporter | |
Comment 9•6 years ago
|
||
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.
|
|
Reporter | |
Comment 10•5 years ago
|
||
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.
|
|
Reporter | |
Comment 11•5 years ago
|
||
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.
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 12•5 years ago
|
||
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?
|
||
Comment 13•5 years ago
|
||
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.
|
||
Comment 14•5 years ago
|
||
Whimboo, do you think you can provide what Markus asked?
|
|
Reporter | |
Comment 15•5 years ago
|
||
(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.
|
|
||
Comment 16•5 years ago
|
||
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.
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 18•5 years ago
|
||
(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
|
|
||
Comment 19•5 years ago
|
||
(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:processeswith the preferencetoolkit.aboutProcesses.showThreadsset totrue, 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.
|
|
Reporter | |
Comment 21•4 years ago
|
||
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?
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 22•4 years ago
|
||
Re-adding needinfo for Jeff in case he could help here.
|
||
Comment 23•4 years ago
|
||
If this is about tab animation then check also this bug 1731590.
|
|
||
Comment 25•4 years ago
|
||
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?
|
||
Updated•4 years ago
|
|
||
Comment 26•4 years ago
•
|
||
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?
|
|
Reporter | |
Comment 27•4 years ago
|
||
I totally missed my needinfo. So thanks a lot Florian for checking that.
|
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 29•3 years ago
|
||
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.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 30•3 years ago
|
||
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.
|
|
Reporter | |
Comment 31•3 years ago
|
||
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?
|
||
Comment 32•3 years ago
|
||
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.
|
|
Reporter | |
Comment 33•3 years ago
|
||
(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%.
|
|
||
Comment 34•3 years ago
|
||
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?
|
||
Comment 35•3 years ago
•
|
||
(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?
|
|
||
Comment 36•3 years ago
|
||
(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.
|
|
Reporter | |
Comment 37•3 years ago
|
||
(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.
|
|
Reporter | |
Comment 38•3 years ago
|
||
(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.
|
|
||
Comment 39•3 years ago
|
||
(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
fontandscriptwere 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.
|
|
Reporter | |
Comment 40•3 years ago
|
||
I was wrong. The problem is persistent even after removing NoScript. I filed bug 1814961 to get this investigated.
|
|
||
Comment 42•3 years ago
|
||
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.
|
|
Reporter | |
Comment 43•3 years ago
|
||
(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.
|
|
||
Updated•2 years ago
|
|
|
||
Comment 45•1 year ago
•
|
||
Henrik, do you still have the machine where you originally reported this? Could you see if it has improved in the meantime? Here's a page that never finishes loading: http://tests.themasta.com/load-never-finishes.php
|
||
Comment 46•1 year ago
|
||
I see around 20% CPU usage in htop when I have 8 of these tabs loading. That seems like more than I would expect?
If I enable the sidebar from Tab Center Redux, there's still one process with 20% usage and another with 100% usage. So that's still very bad. (Not sure if that is an extension-specific problem though or something the core browser should handle better.)
|
|
||
Comment 47•1 year ago
|
||
I agree 20% is not great.
I can reproduce the higher CPU usage with Tab Center Reborn (couldn't find Redux), but it's somewhat orthogonal from this bug. If I disable this SVG filter that's applied to the favicon, the CPU usage is cut in half.
|
|
Reporter | |
Comment 48•1 year ago
|
||
(In reply to Markus Stange [:mstange] from comment #45)
Henrik, do you still have the machine where you originally reported this? Could you see if it has improved in the meantime? Here's a page that never finishes loading: http://tests.themasta.com/load-never-finishes.php
I don't think that there was any improvement in the meantime and we probably have to wait for bug 1812019 to be fixed so that the animation is replaced by a static image if the page doesn't stop loading.
Description
•