4 ms·
I think it would be reasonable to start requiring a compositor for transparency, if it simplifies the code. That way we can have our cake and eat it - most of
by stuaxo 14y ago
I think it would be reasonable to start requiring a compositor for transparency, if it simplifies the code.
That way we can have our cake and eat it - most of the time if you don't have a compositor then transparency doesn't make sense anyway (performance is terrible) - instances include VNC.
I'd certainly be happy with this solution.
(Speaking as a transparent gnome terminal user).
- mpyne 14y agoThat's what we did with Konsole for KDE 4. KWin integrated compositing with a software fallback in case GL wasn't available, so there was simply no need to maintain the KDE 3.5-era fake transparency. Nowadays GNOME Shell simply requires a compositor, or so I thought, so it seems like you could assume one is present. The one issue is supporting the case of running gnome-terminal from non-GNOME environments that also don't have a compositor, but I think it would be fair to give up entirely on supporting that use case. However you might still want to handle the case of the compositor crashing (I think one of the dev's comments in this thread mentioned that), which is admittedly going to be annoying since it involves dealing with X.
- Jasper_ 14y agoWe'd love to do that, but sometimes it doesn't work that way. If you restart the compositor, in order to not crash, you need to unmap and remap your window with a different visual. So the code needs to be there anywhere if your compositor WM doesn't crash.
- towolf 14y agoFrom what I’ve read on another bug from 2011 ARGB Visual could also just stay on even without a compositor.