30% CPU load on Renderer thread when logged in on https://vielfaltmenue.com (before reload)
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/112.0 ID:20230330182947
After logging into https://vielfaltmenue.com the main process' Renderer thread shows a constant high activity of around 30%. Using the DevTools inspector I cannot see any animation listed which might cause that. The load persists even when I switch to another tab. The only way to get rid of the high load is to reload the page after login. Then the CPU load of the Renderer thread drops to normal values. Logging out and logging in again will bring this high CPU load back.
I've created profiles when this high load happens and when not with the Graphics settings:
- Before reload (high CPU load): https://share.firefox.dev/3GF42ZW
- After reload (normal CPU load): https://share.firefox.dev/3GEoUAq
The marker chart of the Renderer thread in the first profile clearly shows a high activity but it's unclear to me where this is coming from.
Note that I also removed each and every node from the DOM tree via the DevTools Inspector but the CPU load stays high. Saving the page as full HTML and loading it from the local disk doesn't reproduce the issue.
Comment 1•2 years ago
|
||
The compositor thread says it keeps sampling an animation in browser.xhtml, was something animated in the chrome? If not, maybe that got out of sync somehow? The normal cpu load profile doesn't have the compositor thread, so I can't check if the sample animation is there too, but I suspect not.
Reporter | ||
Comment 2•2 years ago
|
||
As discussed with Florian already last week the SampleAnimation
entry in the marker chart actually comes from the web content process the above mentioned page is running in. Sadly I missed to include this process in the above profile.
Here an updated profile which has that data: https://share.firefox.dev/3UJ1Fv1
Interestingly I can see the CPU utilization of the main process of around 30% only when the profiler is not running. Once I start profiling the CPU load strangely drops to around 18%. Nevertheless I hope the above new profile will help to get some further details.
Note that there is an initial animation on that page which gets run after the page load but then should stop. I do not see any other animation going on when not interacting with the page.
Comment 3•2 years ago
|
||
Hmm, so the profiler UI is attributing the sample animation to the chrome url of browser.xhtml. Is that a bug then?
Reporter | ||
Comment 4•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #3)
Hmm, so the profiler UI is attributing the sample animation to the chrome url of browser.xhtml. Is that a bug then?
I don't know. I moved the profiler button into the chevron submenu so that it is not visible. So even if there would be an animation it should no longer be shown? Is there a way to figure out from the profile which animation it is exactly?
I've also restarted Firefox in troubleshooting mode to make sure no other extension is causing a side-effect and created a fresh profile. Here you can see the page loaded, and then after 6s I've logged into the page. At least what I can see is that after the login process there seems to be much more activity related to markers.
Profile from troubleshooting mode: https://share.firefox.dev/41voQLk
Reporter | ||
Comment 5•2 years ago
|
||
Timothy, does the new profile help in any way? If not maybe I need to run Instruments to get a profile with the hope that the CPU utilization of the process doesn't go down as well? Thanks.
Comment 6•2 years ago
|
||
I think probably the first thing to investigate here is why we have those SampleAnimation markers going through the whole profile. I haven't looked into compositor animations much before, so perhaps there is someone who knows that code who could investigate relatively quickly?
Reporter | ||
Comment 7•2 years ago
|
||
Ok, I think that I finally got it! The reason why the SampleAnimation
marker was always present on a high rate was that I had a Firefox private browsing window in the background which partly showed a produce page from Amazon. So lets see if the following is more helpful:
https://share.firefox.dev/3UWYOOR
The SampleAnimation
markers are still coming from the expected WebContent process, but when I reload the page it's gone. Checking the WebContent's main thread I can now see a Document Timeline Animations [Style]
RefreshObserver until I reload the page.
Also when I login and close the tab, I can perfectly reopen the tab multiple times without seeing the 30% CPU load. Could it be that the animation of the homepage of that website is somewhat leaking through to the new page?
Reporter | ||
Comment 8•2 years ago
|
||
As it looks like I can only reproduce this problem in Nightly and DevEdition (and maybe beta) builds but not in release. Running mozregression I got the following range:
14:34.30 INFO: Got as far as we can go bisecting nightlies...
14:34.30 INFO: Last good revision: e5ebdee1eac6efa37b7e83861bc179b155f98ae4 (2022-03-03)
14:34.30 INFO: First bad revision: 967ae1edad41790a5a1fde2f1591731784117c7a (2022-03-04)
14:34.30 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e5ebdee1eac6efa37b7e83861bc179b155f98ae4&tochange=967ae1edad41790a5a1fde2f1591731784117c7a
Sadly it's from early March last year and there are no artifact builds available anymore.
Comment 9•2 years ago
|
||
The severity field is not set for this bug.
:gw, could you have a look please?
For more information, please visit BugBot documentation.
Updated•2 years ago
|
Description
•