1798201 - Animating a single SVG path with stroke dashoffset uses unreasonable amount of CPU / GPU resources

Status: UNCONFIRMED

(Core :: Graphics, defect, P3)

Description

[alexandernst]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Safari/605.1.15

Steps to reproduce:

1. Create a test page with the code that I'm providing
2. Open your OS's task manager and find all Firefox's processes
3. Using the mouse, hover over the square and check how the CPU / GPU usage increases

I have a very simple border created with a SVG path. If I try to animate it with it's stroke-dashoffset property, the CPU / GPU usage of Firefox spikes up to 45% (Chrome and Safari have the same bug, but CPU / GPU usage goes up only to 15%). This seems excessive given the fact that I'm animating a single stroke.

Minimal amount of code to reproduce this bug:

CSS:

.outer {
border-radius: 5px;
position: relative;
width: 300px;
height: 300px;
border: 1px solid gray;
}

.border-path {
width: calc(100% + 10px);
height: calc(100% + 10px);
position: absolute;
top: -5px;
left: -5px;
stroke-width: 5;
stroke-dasharray: 8;
stroke-dashoffset: 1000;
stroke-opacity: 0;
fill: transparent;
}

.outer:hover > .border-path {
stroke: red;
stroke-opacity: 1;
animation: draw 30s linear infinite forwards;
}

@keyframes draw {
to {
stroke-dashoffset: 0;
}
}

HTML:

<div class="outer">
<svg class="border-path">
<rect x="0" y="0" width="100%" height="100%" />
</svg>
</div>

Actual results:

CPU / GPU resource usage is unreasonable

Expected results:

CPU / GPU resource usage should stay low

Comment 1

[alexandernst]

Safari bug report: https://bugs.webkit.org/show_bug.cgi?id=247241

Chrome bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1379706

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Mayank Bansal]

Attachment: reporters standalone testcase.html

Comment 4

[Mayank Bansal]

Cant repro on Windows. Possibly only MacOS specific.
https://share.firefox.dev/3U55zfY

Comment 5

[alexandernst]

I just tested this on Linux:

* screen recording: https://www.youtube.com/watch?v=Zh5d-HbrTFA
* profiler result: https://share.firefox.dev/3ztaNKS

and Windows:

* screen recording: https://www.youtube.com/watch?v=r4opq4-YmIo
* profiler result: https://share.firefox.dev/3NmBExy

It seems that on Linux the bug behaves even worse than on Mac (CPU usage spikes from ~1% to ~25%). On Windows, it might seems that it's not happening, but in fact if you look closer at the recording of the desktop you'll notice that the GPU usage goes from 0 to ~2.5% (CPU stays at ~0%). There is definitely something going on in there.

I'll be glad to provide any more information or perform any further tests if you want me to do so.

Comment 6

[alexandernst]

Just to add more info (if that can be helpful): it seems that somebody on stackoverflow already hit this bug in 2015: https://stackoverflow.com/questions/33749245/how-can-i-animate-infinite-marker-movement-down-an-svg-path-without-very-high-cp

Comment 7

[Brad Werth [:bradwerth] | Out until Feb 2025]

I can reproduce on macOS with this profile: https://share.firefox.dev/3TZVph6. For this profile, I waited about 3 seconds, then moused-over the square for about 3 seconds, then moused-off for another 3 seconds. It looks like the primary change is an increase in memory activity, not rendering.

Nical, do we expect SVG to allocate a lot of memory for this case?

Comment 8

[Nicolas Silva [:nical]]

The memory increase in the profile looks about what I'd expect for the CPU tiles the SVG is painted into with a high-dpi screen.