1933527 - Picture caching doesn't work when the content area has a border radius clip

Status: NEW

(Core :: Graphics: WebRender, defect, P1)

Description

[Markus Stange [:mstange]]

Steps to reproduce:

1. Using the Browser toolbox, find a <stack class="browserStack"> element.
2. In the .browserStack rule, add the properties overflow: clip; border-top-left-radius: 50px;
3. Navigate to a page that has an HDR video (e.g. this youtube video) on an HDR-capable screen, for example the built-in screen of a modern Macbook Pro
4. Alternatively, set gfx.webrender.debug.picture-caching to true.

Expected results:
HDR videos should still be HDR.
The picture-caching overlay should look normal when scrolling simple web pages.

Actual results:
HDR videos become non-HDR.
The picture-caching overlay is all-red when scrolling simple web pages.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Sample patch:

diff --git a/browser/themes/shared/tabbrowser/content-area.css b/browser/themes/shared/tabbrowser/content-area.css
index 5c721ee07f0be..d9ab771b77f5c 100644
--- a/browser/themes/shared/tabbrowser/content-area.css
+++ b/browser/themes/shared/tabbrowser/content-area.css
@@ -53,6 +53,8 @@
   position: relative;
   z-index: var(--browser-area-z-index-tabbox);
   margin: 0;
+  overflow: clip;
+  border-top-left-radius: 10px;

   /* stylelint-disable-next-line media-query-no-invalid */
   @media (-moz-bool-pref: "sidebar.revamp") {

HDR videos become non-HDR.

So with the patch above (which uses a smaller radius) you can see that HDR videos only become non-HDR iff they are near the top (for some definition of near), e.g. if they intersect the rounded rect. I think something acceptable for realistic radii would be to promote them as long as they are not near any of the corners, perhaps?

Comment 2

[Markus Stange [:mstange]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

So with the patch above (which uses a smaller radius) you can see that HDR videos only become non-HDR iff they are near the top (for some definition of near), e.g. if they intersect the rounded rect.

Oh phew, that's reassuring! I was testing with a larger radius and this made me think it affected the entire page. But I can confirm that with a radius of 10px it only affects the video if it's intersecting it. With a radius of 25px the danger zone grows to 106px for me, not sure why.

I think something acceptable for realistic radii would be to promote them as long as they are not near any of the corners, perhaps?

Isn't that what seems to be happening, based on these observations?

To make it work even when the corner is intersecting the video, WR would need to tell the native compositor about rounded corner clipping. On macOS CoreAnimation can do rounded corner clipping. On Windows, DirectComposition seems to support this too, at least there is a method called IDCompositionRectangleClip::SetTopLeftRadiusX.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

(In reply to Markus Stange [:mstange] from comment #2)

I think something acceptable for realistic radii would be to promote them as long as they are not near any of the corners, perhaps?

Isn't that what seems to be happening, based on these observations?

Not quite, right? right now it becomes non-HDR if it intersects the rounded rect (at any point, even in places where the right clipping for the layer could be done with a regular non-rounded rect).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Rejiggering to match bug 1933527. I'll move the HDR bits to bug 1933297 since it was filed earlier.

Comment 5

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

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

:nsharpley, since you are the author of the regressor, bug 1908471, could you take a look?

For more information, please visit BugBot documentation.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This will be disabled by pref on release as per bug 1934640.

Comment 7

[Bob Hood [:bhood]]

We will likely be addressing these types of issues in Q1 2025 with the sidebar support.