Hacker News new | comments | show | ask | jobs | submit login

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.




  | 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!

-----


I didn't think that through 100%. You're absolutely right.

-----


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

-----


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).

-----


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.

-----


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.

-----


From what I’ve read on another bug from 2011 ARGB Visual could also just stay on even without a compositor.

-----


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?

-----


  | 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?

-----


> 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.

-----


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.

-----


> 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?

-----


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.

-----


With hindsight, yes, we'd love to do things differently. Saying "you should have done" doesn't really help the current situation here.

The gsettings port broke stuff and reintroduced problems. It was long overdue. This means that cutting features to get things out of the door might happen.

If I had to guess without debugging, I might guess that the 'changed' signals were firing at different times in comparison to when the slider was being adjusted that means that changing the background wasn't ordered 100% correct. The code stems back to 1996 -- it's possible that assumptions like these are being made.

-----


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.

-----


Only looking for explanations. Really super grateful that Jasper_ added some, but it’s still not entirely clear.

-----


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

-----




Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: