macOS: fix opacity handling #3722
Conversation
kchibisov
force-pushed
the
kchibisov/macos-fix-opacity
branch
from
fbaad91 to
cc59407
Compare
madsmtm
left a comment
madsmtm
left a comment
There was a problem hiding this comment.
I'm not against this per-say, but I think we should experiment and finish this in Alacritty first, and only once we know what the desired behaviour is, then we can consider doing the change in Winit.
|
I mean, that breaks not only alacritty, but basically everything that wants to put something transparent on screen, like glutin example, etc, etc. |
|
I'd also note, that it won't align with how all platforms work in winit, so not setting proper transparency sounds like we're not trying to do reliable cross platform behavior. |
There was a problem hiding this comment.
Sorry it took me a while, I went and tested this with the following rendering methods:
- Raw
CALayer(softbufferwith a fix to make alpha channels work there). - OpenGL (
glutin). - Metal (
metalwithlayer.set_opaque(false)). CGContext(cacao).NSView's positioned with different background colors (cacao).
And indeed for all of them, the correct behaviour is to set the background color to clearColor, setOpaque didn't seem to even do anything (!).
Also noting for the future: -[NSWindow setAlphaValue:] is similar to what we're doing here, but distinct in that it sets the opacity of the entire window, including decorations / title bar, and this cannot be "overridden" by rendering something with full opacity.
Approved after comments are resolved.
| unsafe { NSColor::windowBackgroundColor() } | ||
| }; | ||
|
|
||
| self.window().setBackgroundColor(Some(color).as_deref()); |
There was a problem hiding this comment.
Nit: Slightly clearer.
| self.window().setBackgroundColor(Some(color).as_deref()); | |
| self.window().setBackgroundColor(Some(&color)); |
This is not desired in most cases, because it makes the text transparent as well. So should just leave it. |
kchibisov
force-pushed
the
kchibisov/macos-fix-opacity
branch
from
cc59407 to
55815d7
Compare
| self.window().setOpaque(!transparent) | ||
| self.window().setOpaque(!transparent); |
There was a problem hiding this comment.
setOpaqueis a hint for compositor and nothing more, IIRC. Which means that handling it reduces the load on the compositor, but that's about it. It doesn't actually check whether something is opaque/not.
Maybe document that here?
kchibisov
force-pushed
the
kchibisov/macos-fix-opacity
branch
from
55815d7 to
899e745
Compare
Not using `NSColor::clearColor()` results in Quartz thinking that the window is not transparent at all, which results in artifacts. However, not setting the `windowBackgroundColor` in `Window::set_transparent` results in border not properly rendered. Fixes: 94664ff (Don't set the background color)
kchibisov
force-pushed
the
kchibisov/macos-fix-opacity
branch
from
899e745 to
aa0f4be
Compare
Not using
NSColor::clearColor()results in Quartz thinking that the window is not transparent at all, which results in artifacts.However, not setting the
windowBackgroundColorinWindow::set_transparentresults in border not properly rendered.Fixes: 94664ff (Don't set the background color)
--
This is kind of a revert, given that alacritty/alacritty#7965 not really doing anything and the window is not really tranparent as it should (it kind of is, but the value is different to what it should be and Quartz glitches behind the window with damage tracking).
Though, Quartz seems to generally glitch with e.g. shadows if you reload opacity with these changes as well. Maybe we should do something completely different, but I only care to fix the regression.