STR:

1. Visit https://www.axo.dev , in a maximized browser, on an Ubuntu system with 125% display scaling in the Ubuntu settings app. (I'm using a resolution of 3440x1440, too, FWIW).
2. Scroll (with arrow keys or mousewheel or by clicking and dragging scrollbar)

ACTUAL RESULTS:
Scrolling is quite laggy -- the scroll operation feels a bit delayed and low-framerate.

EXPECTED RESULTS:
Responsive scrolling.

Profile: https://share.firefox.dev/3yblArO

Looks like most of our time is spent in WebRender paint operations; hence, starting this out in the Graphics:WebRender component.

For comparison:
Chrome scrolls quite responsively when I perform the same steps there on the same device.
Other websites (e.g. this bugzilla bug-entry page, https://news.google.com/ ) scroll quite responsively in Firefox.
Also: this same website scrolls responsively in Firefox if I view it with my display resolution set to 100% or 200%. I've only noticed issues at 125%. So maybe there's some connection to being rendered at a fractional OS zoom-level?

For comparison, here's a "good" profile of me scrolling the same site with 100% OS-level display scaling (still using the same display resolution, 3440x1440, i.e. same number of dev pixels):
https://share.firefox.dev/3EXBWrT
Paint operations are in the 10-20ms range, and it doesn't feel laggy.

Whereas, with 125% display scaling, paint operations are an order of magnitude slower (on the order of 80-100ms, and sometimes batched into a group of several ~100ms back-to-back paints that collectively result in a single visual change like here: e.g. https://share.firefox.dev/3ycksnU

(Looking at the flame graph for the good vs. bad profile for the Render track, I'm not seeing any huge differences in where we're spending time, at first glance. Slightly different proportion of time in different sections, but overall a similar distribution; just "more overall" in the "bad" profile.)

I do see this at the bottom of my just-posted about:support:

DMABUF_SURFACE_EXPORT	
default	blocked	Blocklisted by gfxInfo	Blocklisted; failure code FEATURE_FAILURE_BROKEN_DRIVER

That might be relevant; not sure.

It's something to do with the subtle animation on the .axo-gradient-text rule (which matches the container for all of the >o_o< text). If I untick animation-name: animation-gradient-title; in that CSS rule, the performance issue seems to go away.

I can reproduce a noticeable performance difference in the attached testcase between Firefox and Chrome, regardless of my display-scaling level, actually. The animation is noticeably worse in Firefox, and I can trigger checkerboarding by scrolling to the opposite end of the document, vs. I'm not seeing checkerboarding in Chrome.

(I think Firefox-at-125%-display-scaling is just particularly bad since, for whatever reason, on Wayland, that ends up meaning that we render with a devicePixelRatio of 2 to a content area that is large enough such that it will fit the window when scaled down to the actual display-scaling level of 1.25x. So we end up having to render as if the monitor were 60% larger (2/1.25 = 1.6). I need to file a separate bug on that; I've noticed it causing other issues like bug 1818837. But in any case, there's still a performance issue here even when I switch to "simple" 100% display scaling.)

Probably a duplicate of bug 1598740, actually.