User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

1. Open https://discord.com/hypesquad or https://www.sketch.com/for-teams/
2. 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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

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.

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.

(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.)

Looks like the profiler causes a deadlock during shmem allocation?

Thanks. I spun off bug 1658847 for that profiler-caused deadlock. Transferring ni=gerald over there.

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.

(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!).

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).

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:

https://www.reddit.com/r/firefox/comments/lqmo68/why_is_firefox_lagging_the_animation_is_an_svg/

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.

Archived version may still have perf issues

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.