Bugzilla

(In reply to Jan Alexander Steffens [:heftig] from comment #18)
> No, this was just in relation to your case of `mozilla.widget.use-argb-visuals = false` but this doesn't interest me at all. It's just puzzling that it doesn't actually use alpha-less "visuals", i.e. buffer formats when disabled.

Visual means how the surface is displayed. It's not related to how is stored internally - the alpha channel is discarded when RGB visual is used.
We can't use RGB surface format for regular windows as we want the transparent corners. That may be changed when mozilla.widget.use-argb-visuals=false and there isn't any performance penalty. That may be used for PIP windows for instance which are not transparent.

> The normal case still needs the entire surface to be set as opaque, minus the corners, which remain transparent. 
Corners subtraction is Bug 1584932.

> Right now the entire surface is transparent.
nsWindow::UpdateOpaqueRegion() it's called on toplevel window which is another bug.

(In reply to Jan Alexander Steffens [:heftig] from comment #18)
> No, this was just in relation to your case of `mozilla.widget.use-argb-visuals = false` but this doesn't interest me at all. It's just puzzling that it doesn't actually use alpha-less "visuals", i.e. buffer formats when disabled.

Visual means how the surface is displayed. It's not related to how is stored internally - the alpha channel is discarded when RGB visual is used.
We can't use RGB surface format for regular windows as we want the transparent corners. That may be changed when mozilla.widget.use-argb-visuals=false and there isn't any performance penalty. That may be used for PIP windows for instance which are not transparent.

> The normal case still needs the entire surface to be set as opaque, minus the corners, which remain transparent. 

Corners subtraction is Bug 1584932.

> Right now the entire surface is transparent.

nsWindow::UpdateOpaqueRegion() it's called on toplevel window which is another bug.