See bug 1852584.

This is visible on Linux if you flip widget.gtk.rounded-bottom-corners.enabled to true, and restart.

This blocks getting rounded bottom corners on Linux to work, and it's a massive perf regression on SWGL specially.

ni? me to post some profiles with / without the feature and with / without SWGL enabled.

Scrolling Youtube, HW WR:

• No rounded bottom corners: https://share.firefox.dev/3PNT35s
• With rounded bottom corners: https://share.firefox.dev/48l36WP

SW WR:

• No rounded bottom corners: https://share.firefox.dev/45XrcVP
• With rounded bottom corners: https://share.firefox.dev/3Rpyttf

Comparing the two SW-WR profiles, the renderer thread is much more busy with the rounded bottom corners. Glenn, is that helpful? (ni?ing since you asked for the profiles in bug 1852584)?

You should be able to reproduce trivially flipping the pref mentioned in comment 0 and restarting.

Part of the issue here is that the rounded clip was rounded only at the bottom. Bug 1854360 seems to help looking at local profiles. However we still need bottom-only clips for windows where the OS draws the titlebar...

How hard would be to optimize the fast path to handle uniform-or-zero clip radii?

Glenn, feel free to adjust the severity on this one if needed after you give it a look.

It should be straightforward to handle uniform-or-zero as part of the fast path. We haven't done it in the past as we assumed it was rare, but it should be easy to handle, I think.

Set release status flags based on info from the regressing bug 1854360

This is not a regression from bug 1854360. Bug 1854360 is a workaround for the case where all the corners are rounded.