Bug 1592739 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

With the current default Webrender configuration (i.e. no OS compositor integration), vibrancy works as follows:
 - The window contains an opaque CALayer for the window background color.
 - Then there's the CALayer from a vibrant NSVisualEffectsView. This knocks out the window background color.
 - Then there's a full-window CALayer with WebRender's rendering. Within this layer, OpenGL painting does the following:
   - First, it draws a full-window sized opaque window background color.
   - Then it draws the web content.
   - Then it draws a "clear rect" primitive, which erases the window background color drawing in the tab bar again.
   - Then it draws the content of the tab bar and the rest of the chrome on top.

The "clear rect" approach is hard to make work with WR OS compositor surfaces. The semantics of the "clear rect" primitive ask for the pixels to be cleared across the entire stack of WebRender rendering, which can consist of multiple overlapping OS compositor surfaces.
It would be much simpler for WebRender if there was no "erasing". Instead of drawing a background color and then clearing it, we should just not draw that background color.
And the easiest way to achieve *that* is probably to change the front-end CSS so that there's no CSS background-color definition on the root element of the window document.

So I think what I'll do is the following:
 - Remove the CSS background-color from the stylesheet and replace it with `-moz-appearance: window`. (Reverting bug 461366, which is now 11 years old.)
 - On macOS, treat `-moz-appearance: window` similarly to how `-moz-appearance: -moz-win-glass` is treated on Windows 7: Make Gecko leave the background transparent, but make sure the *OS window* doesn't actually turn transparent.
 - At this point there will be nothing to erase anymore, and we can get rid of the "clear rect" display items.
With the current default Webrender configuration (i.e. no OS compositor integration), vibrancy works as follows:
 - The window contains an opaque CALayer for the window background color.
 - Then there's the CALayer from a vibrant NSVisualEffectsView. This knocks out the window background color.
 - Then there's a full-window CALayer with WebRender's rendering. Within this layer, OpenGL painting does the following:
   - First, it draws a full-window sized opaque window background color.
   - Then it draws the web content.
   - Then it draws a "clear rect" primitive, which erases the window background color drawing in the tab bar again.
   - Then it draws the content of the tab bar and the rest of the chrome on top.

The "clear rect" approach is hard to make work with WR OS compositor surfaces. The semantics of the "clear rect" primitive ask for the pixels to be cleared across the entire stack of WebRender rendering, which can consist of multiple overlapping OS compositor surfaces.
It would be much simpler for WebRender if there was no "erasing". Instead of drawing a background color and then clearing it, we should just not draw that background color.
And the easiest way to achieve *that* is probably to change the front-end CSS so that there's no CSS background-color definition on the root element of the window document.

So I think what I'll do is the following:
 - Remove the CSS background-color from the stylesheet and replace it with `-moz-appearance: dialog`. (Reverting bug 461366, which is now 11 years old.)
 - On macOS, treat `-moz-appearance: dialog` similarly to how `-moz-appearance: -moz-win-glass` is treated on Windows 7: Make Gecko leave the background transparent, but make sure the *OS window* doesn't actually turn transparent.
 - At this point there will be nothing to erase anymore, and we can get rid of the "clear rect" display items.

Back to Bug 1592739 Comment 0