1689453 - Animated arrow on https://www.augencentrum-dresden.de/ causes 20% extra CPU load in mozilla::wr::RenderThread::HandleFrameOneDoc

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:87.0) Gecko/20100101 Firefox/87.0 ID:20210127093943

Having https://www.augencentrum-dresden.de/ open causes a permanent extra 20% CPU load on the main process. Checking the generated gecko profile it looks fully related to WebRender. There is a lot of time spend in mozilla::wr::RenderThread::HandleFrameOneDoc.

https://share.firefox.dev/3abeY0m

Note that this high CPU load comes all from the animated cursor at the bottom of the page. Removing it from the DOM drops the CPU load to a reasonable value.

Having the same page open with Safari shows a 4% CPU load only.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Can you grab a profile without screenshots? I.e. using "Firefox Graphics" preset.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sure, here it is: https://share.firefox.dev/2MCtZjm

Comment 3

[Florian Quèze [:florian]]

There's also a lot of time spent by the profiler capturing stacks of native allocations. This feature of the profiler should be used only when trying to troubleshoot a memory issue; it causes a lot of overhead that makes the other measurements less acurate than usual.

For bugs about excessive CPU use, trying the "CPU Utilization" experimental feature would be interesting. To be able to see the results, you need to set devtools.performance.recording.ui-base-url to https://deploy-preview-3098--perf-html.netlify.app from about:config.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

The arrow has animated opacity and transform. Safari might be running the entire thing in CoreAnimation.

Comment 5

[Nicolas Silva [:nical]]

This is similar to bug 1562433..

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

There's also a lot of time spent by the profiler capturing stacks of native allocations. This feature of the profiler should be used only when trying to troubleshoot a memory issue; it causes a lot of overhead that makes the other measurements less acurate than usual.

Good to know. Will remember that. Here is the newly generated profile: https://share.firefox.dev/3j1jbI2

For bugs about excessive CPU use, trying the "CPU Utilization" experimental feature would be interesting. To be able to see the results, you need to set devtools.performance.recording.ui-base-url to https://deploy-preview-3098--perf-html.netlify.app from about:config.

I tried that yesterday but the page didn't load the profile for me. I tried again and now it worked: https://share.firefox.dev/3cixnLj

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)

The arrow has animated opacity and transform. Safari might be running the entire thing in CoreAnimation.

The element using the particular animation here has the following CSS definition:

.learn-more-button::before {
    content: '\203B';    
    animation: bounceOneWayDown 1.5s linear infinite;
    animation-name: bounceOneWayDown;
    animation-duration: 1.5s;
    animation-timing-function: linear;
    animation-delay: 0s;
    animation-iteration-count: infinite;
    animation-direction: normal;
    animation-fill-mode: none;
    animation-play-state: running;
}

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)

The arrow has animated opacity and transform. Safari might be running the entire thing in CoreAnimation.

And that is what we don't make use of yet? Is there a bug that is about adding support for CoreAnimation?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sean, could you give an explanation why this bug is a qf-?

Comment 8

[Sean Feng [:sefeng211]]

We did this during perf triage. I recall it was mainly because this bug had already been tracked by the graphic team, so we'd like to remove it from our queue.

Comment 9

[Florian Quèze [:florian]]

I captured a profile of it using the Graphics profiler preset: https://share.firefox.dev/3KzyGnf

Most of the CPU use is in the Renderer thread.

I noticed that the CPU use percentage increases when the window isn't active (this is visible in the profile at the range 14s-22s). I don't see an obvious explanation from the profile, I wonder if it might just be that OS X schedules tasks for applications having only inactive windows on power efficiency cores and when the window is focused it get scheduled on the performance cores, resulting in shorter CPU times for the same work load.

The page has a transform and opacity CSS animation on the green arrow, as already noted in comment 1.
The page also uses requestAnimationFrame continuously.

Is there anything actionable in this profile or in this bug in general? The CPU use (about 40% of a CPU core in the parent process, half of it in the Renderer thread) feels like a lot to me to animate so few pixels (it's an area of 62 x 15 px).

Comment 10

[Markus Stange [:mstange]]

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

I captured a profile of it using the Graphics profiler preset: https://share.firefox.dev/3KzyGnf

I noticed that the CPU use percentage increases when the window isn't active (this is visible in the profile at the range 14s-22s). I don't see an obvious explanation from the profile, I wonder if it might just be that OS X schedules tasks for applications having only inactive windows on power efficiency cores and when the window is focused it get scheduled on the performance cores, resulting in shorter CPU times for the same work load.

Whoa, that's an interesting hypothesis! It sounds plausible, too. It looks like all functions slow down by a roughly uniform amount. It's fun to see this by making a fixed size preview selection and then sweeping it over the various parts of the timeline, and looking at how the flame graph shape updates.

I do agree it sounds like we shouldn't need to use that much CPU to animate such a small area.