Slow rendering of animated SVG transforms at https://discord.com/hypesquad
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: vlkv, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
Attachments
(1 file)
7.24 MB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
- Open https://discord.com/hypesquad or https://www.sketch.com/for-teams/
- Scroll down
Actual results:
The page is freezing, animations look like 3-4 fps
Expected results:
Animations should be displayed in 60 fps
Hardware acceleration is turned off on my computer, but animations work well in Safari or Chrome, where I turned off acceleration as well.
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
Not sure what animations you're seeing that are slow but we're going to need a reduced testcase attached to the bug rather than a website that can change at any time.
Comment 4•4 years ago
•
|
||
I can reproduce (on Linux, Firefox Nightly). No scrolling needed in my case; just load the hypesquad page.
The animation of the dude holding a flag (with a backpack full of papers) is extremely slow/stuttery for me. Much smoother in Chrome.
Strangely, the animation pauses when I start capturing a profile (possibly because some of the overhead of our profiler instrumentation for a codepath that this testcase is hitting really hard?)
Having said that, here's a profile that I captured: https://share.firefox.dev/2DZyFeS
The element in question is in <div class="human-animation">
and it contains a large in-content <svg>
element with lots of <g>
subtrees that have transform=matrix(...)
attributes that are constantly being updated via JavaScript.
Comment 5•4 years ago
•
|
||
spun-off-to-another-bug |
(In reply to Daniel Holbert [:dholbert] from comment #4)
Strangely, the animation pauses when I start capturing a profile (possibly because some of the overhead of our profiler instrumentation for a codepath that this testcase is hitting really hard?)
Yeah, I'm having a real hard time getting the profiler to be helpful here, unfortunately. When I start profiling, the animation freezes & we just hang in posix_fallocate
for some reason. Here's a longer profile showing the same thing: https://share.firefox.dev/3aiSdXQ
mstange, do you know what's going on here?
(For what it's worth: on my machine, WebRender is disabled by default. Not sure that matters too much, though; because when I enable WebRender, the animation is still noticeably worse/slower than in Chrome, and I still see the "animation grinds to a halt when profiler starts" issue.)
Comment 6•4 years ago
|
||
spun-off-to-another-bug |
Looks like the profiler causes a deadlock during shmem allocation?
Updated•4 years ago
|
Comment 7•4 years ago
|
||
spun-off-to-another-bug |
Thanks. I spun off bug 1658847 for that profiler-caused deadlock. Transferring ni=gerald over there.
Comment 8•4 years ago
|
||
Fortunately, the profiler works in Firefox 79 release, and I was able to generate a profile there.
WebRender disabled (default): https://share.firefox.dev/2XUzlcN
WebRender enabled (forced): https://share.firefox.dev/30QQFkH
Observations:
- Superficially, the animation is perhaps a bit more responsive with WebRender enabled, but Chrome is still noticeably smoother.
- In the "WebRender disabled" profile, we seem to be blocking on expensive
mozilla::layers::CompositorBridgeChild::FlushAsyncPaints
calls. - The "Webrender enabled" profile is harder for me to interpret, so I won't comment on it.
Reclassifying as Graphics:Layers for now.
Comment 9•4 years ago
|
||
(clearing ni from comment 3; a reduced testcase would be excellent, but the URLs from comment 0 seem to serve for now.)
Daniel, I found the profiler regression started with bug 1582954, which introduced posix_fallocate
.
I was able to find this on my laptop by looking at profiles, however I don't experience the super-slow rendering described in this bug, so I'm not sure if that bug 1582954 is also the cause of this bug here -- though it seems unlikely, since this bug looks more like a graphics issue...
But just in case, could you please try on your computer, see if bug 1582954 started it?
And/or you could try ./mach mozregression -g 79
yourself, it only took me a dozen tests to find the profiler-regression patch (and I had more work to do, to setup the profiler in each test!).
Comment 11•4 years ago
|
||
Thanks for getting to the root of that profiler lockup, Gerald!
I don't think this perf issue was introduced by bug 1582954 -- I can reproduce it in builds from a year ago (2019-08-01), and also in Firefox 79 (your hypothetical "good" range for mozregression). See e.g. my profile links in comment 8, which I captured using Firefox 79 release.
So: this doesn't seem to be a regression (or not a recent one at least).
Updated•4 years ago
|
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Assuming this is the same issue, here's some more info:
It also happens on Windows 20H2 with Firefox 83b7 (WebRender on): https://share.firefox.dev/3oZ9Tin
And here's a recording of the difference between Firefox and Vivaldi:
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Comment hidden (me-too) |
Updated•1 years ago
|
Updated•1 years ago
|
Comment 15•1 years ago
|
||
The sites seem to have changed. There's no "dude holding a flag (with a backpack full of papers)" any more that I can see.
Comment 16•1 years ago
|
||
Archived version may still have perf issues
Comment 17•1 years ago
•
|
||
Using that archive.org testcase: I'm not noticing jank (nothing like the low framerates in comment 12), but that might just be due to me using a fairly powerful computer.
What I do see is ~10x higher CPU usage from Firefox vs. Chrome, as reported in top
. When viewing gregp's archive.org link:
- Firefox shows ~200% CPU usage, attributed to our parent process PID.
- Chrome shows ~20% CPU usage, split between two PIDs.
Here's a profile (using graphics presets) with today's nightly, just watching this page animate: https://share.firefox.dev/3N1uM9t
Unsurprisingly, it looks like the WRWorkerLP threads are pretty busy here.
Description
•