1979083 - Picture caching doesn't work when widget.gtk.rounded-bottom-corners.enabled is enabled

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Mauro V [:cheff]]

Attachment: broken.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

Enabling widget.gtk.rounded-bottom-corners.enabled in about:config makes picture caching start breaking up again.

Actual results:

Picture caching breaks and scrolling optimizations stop working

Expected results:

Picture caching to work as it would when the preference is disabled. It does work when the window has a border radius just on the top part.

Comment 1

[Mauro V [:cheff]]

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1933527

Comment 2

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

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

So I debugged this a little, and I can confirm that removing this fixes it (the tabbrowser-tabbox in particular).

That seems surprising, since that transform is a no-op for painting purposes... Glenn, do you know what might be going on?

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Also, I realized that this won't work when the sidebar is additionally shown (because that hits the "more than one rounded rect clip" condition). But I think in this case we could do something smart like combining the clips... Glenn does that seem feasible? If so I'd be happy to try to poke....

Comment 5

[Emilio Cobos Álvarez [:emilio]]

That is, for the sidebar shown case we'd be hitting this, but I think in this case we could relax it and build a rounded rect clip that combines the sidebar clip and the bottom border radius clip...

Comment 6

[Emilio Cobos Álvarez [:emilio]]

ni? to poke at this (no promises tho)

Comment 7

[Emilio Cobos Álvarez [:emilio]]

I took a quick look and the clusters here are so different with and without the transform that I'm not sure where to begin... Glenn any pointers would be appreciated

Comment 8

[Glenn Watson [:gw] | PTO until 6th Jan]

Attachment: s1_s2.patch

Attached is a patch that shows the diff between a webrender capture for the first ~2000 lines with/without that preference set.

It starts off looking roughly like I'd expect (the root clip changes from rounded corners at the top to same corners at the bottom).

But then it gets a bit weird - there seems to be almost a new clip-chain for every subsequent item, and then at various places throughout the diff a new Clip is defined with the same rounded rect params as the root clip, and gets referenced in clip-chains for subsequent items.

Even if the WR clip tree logic is able to find the correct shared clips to apply here, it seems like a lot of extra display items that's probably not great for performance (I haven't checked it breaks the shared clip logic building, but I suspect that's what is happening?).

Would it be feasible to make all the items refer to the same clip(chain) instead of defining new ones? Even if that still breaks picture cache scrolling it'd be easier to debug what's happening here.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Let me try to debug that.

Comment 10

[Emilio Cobos Álvarez [:emilio]]

But yeah the main difference is that the clip moves from the navigator toolbox (the header bar) to the body.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

I see, thanks. Bug 2006062 should help with that as far as I can tell. I can still repro picture caching being broken with that pref, and it working if I do:

diff --git a/browser/themes/shared/sidebar.css b/browser/themes/shared/sidebar.css
index a28d31bf3a564..258e2e670e5db 100644
--- a/browser/themes/shared/sidebar.css
+++ b/browser/themes/shared/sidebar.css
@@ -241,7 +241,7 @@ sidebar-main,
   transform-origin: 0 0;
   /* will-change would cause us to be considered animated unconditionally, see
    * bug 1930674 */
-  translate: 0;
+  /* translate: 0; */
 }

 #sidebar-main {

Does that help?

Comment 12

[Glenn Watson [:gw] | PTO until 6th Jan]

I won't have a chance to investigate it this week unfortunately, but I'll assign to myself and debug it once back from PTO.