4 ms·

I'm that friend. I said to Jonanin: "If you want to know exactly, it's a lot of very, very tricky code that's easy to get wrong, hard to get right, and even whe

by Jasper_ 13y ago

I'm that friend. I said to Jonanin: "If you want to know exactly, it's a lot of very, very tricky code that's easy to get wrong, hard to get right, and even when it looks like it's working, there's a large perf cost if it's not 100% right.", but it seems he didn't paste that part of the chatlog. I can't speak for why Christian Perch spoke the way he did, but he knows that he shouldn't do it anymore. So, let's go into more details. There are a few ways to get real transparency for windows under X. First of all, there's _NET_WM_OPACITY which is handled by the compositor window manager, and that's the replacement workaround suggested, but some think it's not appropriate enough. Fine. Second, there's "psuedotransparency", which is expensive on a modern system. Basically, you copy parts of the root window, excluding your window, and then paint it under your window. Every time some other window updates, you need to re-fetch contents. This is wasteful, but it's how transparent terminals were implemented in the 80s. To implement it, there's a bunch of MMX (yes, MMX) code that's been copy/pasted to every project. The only existing program that uses pseudotransparency that's still maintained is XChat/HexChat. Third, there's RGBA visuals, which require a compositing window manager. The issue here is that the RGBA visual isn't always around: it's dependent on your window being redirected to an off-screen pixmap. If the compositing WM restarts, or you close down the compositing WM and start up a traditional WM, or close down the traditional WM and start up a compositing WM, you have to basically close your window and re-open it. This is racy and bad to do at WM startup time, and accounts for a few bugs/crashes in the WM or in gnome-terminal. Furthermore, closing and restarting the window means that the new window is now on top of the stack whenever you restart the WM. It's really ugly behavior all around, and we did an informal poll and found that almost nobody was using transparent terminals, and decided to drop the code. X just isn't meant for modern graphics.

towolf 13y ago
You forgot to mention that the ARGB Visual type was working well enough for years, ever since xcompmgr was around, all trough compiz and GS. And the GS → metacity → GS cycle was not crashy here at all. It worked. And now you’re getting into Wayland territory. All the more reason to make sure that windows with alpha maps work. You can keep the old code around in the meantime. Also, making a poll in your 50 people IRC channel is not a very meaningful sample size is it?
- pyre 13y ago
  | Also, making a poll in your 50 people IRC channel | is not a very meaningful sample size is it? They just polled the IRC channel? Really? That just seems like the definition of a 'circle jerk.' Was the assumption that all or a majority of users technical enough to use the terminal would be in the IRC channel?
  - towolf 13y ago
    > Really? No idea. That’s what I derive from "we had an informal poll". Since they hang out on IRC that is probably where it happened.
- Jasper_ 13y ago
  The old code didn't work after the port to GSettings. It crashed in weird places. That's why it was "#if 0"'d around in the GSettings port commit. As I said, the original intention was to fix it, but minds were changed.
  - towolf 13y ago
    > but minds were changed. So what does it take to make the minds change back again? When I stare at opaque terminals all day I get severely perceptually understimulated to the point that I fear becoming an automaton. But with some sliding animations and a bit of flower poking through it soothes my nerves. Is that not enough reason?
  - towolf 13y ago
    I can’t see how Gsettings has anything to do with opacity and the compositor. Perhaps separating these things out in different commits would’ve been smarter to begin with.
    - jodrellblank 13y ago
      I can’t see how Gsettings has anything to do with opacity and the compositor. You are implying that because you don't know about the connection, there must not be one? Perhaps separating these things out in different commits would’ve been smarter to begin with. 20/20 hindsight criticism from someone watching from the sidelines? Helpful.
towolf 13y ago
By the way. Ubuntu was using transparent background by default [1]. So it’s fair to say that at bare minimum tens of thousands of people were using this code path. [1] https://bugzilla.gnome.org/show_bug.cgi?id=692609#c2 https://bugzilla.gnome.org/show_bug.cgi?id=692609#c2
pyre 13y ago
| First of all, there's _NET_WM_OPACITY which is | handled by the compositor window manager, and that's | the replacement workaround suggested, but some | think it's not appropriate enough. Fine. This is the part that I don't understand. The whole point of 'terminal transparency' is to make the background transparent while leaving the text opaque. This 'workaround' makes everything transparent, which defeats the purpose of leaving the text readable. I don't personally use terminal transparency, but it does not seem logical that someone could see _NET_WM_OPACITY as a replacement for this. This seems like a really weak (and poorly thought out) attempt to 'throw a bone' to the people that want the feature that's being removed. Sure, we're removing the NY strip steak from our menu, but there's always the hamburger, that has beef in it too. You can even add steaksauce to the burger!
- Jasper_ 13y ago
  I didn't think that through 100%. You're absolutely right.
stuaxo 13y 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 13y ago
  That'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_ 13y ago
  We'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 13y ago
    From what I’ve read on another bug from 2011 ARGB Visual could also just stay on even without a compositor.
chris_wot 13y ago
Your "informal poll" evidently didn't include the userbase.

by Jasper_ 13y ago

towolf 13y ago

You forgot to mention that the ARGB Visual type was working well enough for years, ever since xcompmgr was around, all trough compiz and GS. And the GS → metacity → GS cycle was not crashy here at all. It worked. And now you’re getting into Wayland territory. All the more reason to make sure that windows with alpha maps work. You can keep the old code around in the meantime. Also, making a poll in your 50 people IRC channel is not a very meaningful sample size is it?

pyre 13y ago
| Also, making a poll in your 50 people IRC channel | is not a very meaningful sample size is it? They just polled the IRC channel? Really? That just seems like the definition of a 'circle jerk.' Was the assumption that all or a majority of users technical enough to use the terminal would be in the IRC channel?
- towolf 13y ago
  > Really? No idea. That’s what I derive from "we had an informal poll". Since they hang out on IRC that is probably where it happened.
Jasper_ 13y ago
The old code didn't work after the port to GSettings. It crashed in weird places. That's why it was "#if 0"'d around in the GSettings port commit. As I said, the original intention was to fix it, but minds were changed.
- towolf 13y ago
  > but minds were changed. So what does it take to make the minds change back again? When I stare at opaque terminals all day I get severely perceptually understimulated to the point that I fear becoming an automaton. But with some sliding animations and a bit of flower poking through it soothes my nerves. Is that not enough reason?
- towolf 13y ago
  I can’t see how Gsettings has anything to do with opacity and the compositor. Perhaps separating these things out in different commits would’ve been smarter to begin with.
  - jodrellblank 13y ago
    I can’t see how Gsettings has anything to do with opacity and the compositor. You are implying that because you don't know about the connection, there must not be one? Perhaps separating these things out in different commits would’ve been smarter to begin with. 20/20 hindsight criticism from someone watching from the sidelines? Helpful.

towolf 13y ago

By the way. Ubuntu was using transparent background by default [1]. So it’s fair to say that at bare minimum tens of thousands of people were using this code path. [1] https://bugzilla.gnome.org/show_bug.cgi?id=692609#c2 https://bugzilla.gnome.org/show_bug.cgi?id=692609#c2

pyre 13y ago

| First of all, there's _NET_WM_OPACITY which is | handled by the compositor window manager, and that's | the replacement workaround suggested, but some | think it's not appropriate enough. Fine. This is the part that I don't understand. The whole point of 'terminal transparency' is to make the background transparent while leaving the text opaque. This 'workaround' makes everything transparent, which defeats the purpose of leaving the text readable. I don't personally use terminal transparency, but it does not seem logical that someone could see _NET_WM_OPACITY as a replacement for this. This seems like a really weak (and poorly thought out) attempt to 'throw a bone' to the people that want the feature that's being removed. Sure, we're removing the NY strip steak from our menu, but there's always the hamburger, that has beef in it too. You can even add steaksauce to the burger!

Jasper_ 13y ago
I didn't think that through 100%. You're absolutely right.

stuaxo 13y 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 13y ago
That'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_ 13y ago
We'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 13y ago
  From what I’ve read on another bug from 2011 ARGB Visual could also just stay on even without a compositor.

chris_wot 13y ago

Your "informal poll" evidently didn't include the userbase.