Transparency broken on X11

[chrisduerr]

Apparently since the 0.20 update to glutin (which bumped the major of winit), there have been some issues with transparency on the X11 backend.

The problem seems to boil down to with_transparency(true) acting like with_transparency(false). So there are no crashes, but a fully transparent window is displayed as a black window.

The issue has been reported to Alacritty here: alacritty/alacritty#2254

Other than X11 I haven't been able to find any significant similarities between the parties for which this works and for whom it doesn't. Not everyone on X11 is experiencing this issue.

The exact winit commit has not been bisected yet either, though that has already been requested.

[chrisduerr]

Turns out I can not read and the latest master does resolve the issue. Sorry for the noise.

[chrisduerr]

Apparently it looks like this was NOT fixed on all systems.

[chrisduerr]

To provide a little more detail: It looks like this got worse. Even my system which was originally unaffected is not able to run transparent windows anymore.

[goddessfreya]

Confirmed, I can also repo this. Will look into it next week if I remember.

[elinorbgr]

Apparently the x11 backend just does not check if with_transparecy(..) has been called on the builder at all (git grep transparent returns nothin).

Possibly introduced by rust-windowing/winit@19dd961

[goddessfreya]

We need to be checking that the alphaMask returned from XRenderFindVisualFormat is > 0. I've put together a small patch for glx only, but it does not yet account for raw windows. I'll drop a PR once it accounts for those edge cases and has egl support.

[goddessfreya]

This has been fixed for events loop v2: #1146

Should be noted that it is non functional for egl, due to a mesa bug. glfw/glfw#715 (comment)

After mulling about it for a while, I've come to the conclusion that accounting for raw contexts would likely require exposing a good portion of glutin's internals. If someone is interested, they are free to file a PR which does that in a clean way.

[chrisduerr]

@zegentzy Do you know if there is an upstream bug in mesa for this? And if there's any workaround that could be implemented until such a bug would be resolved?

Not supporting background transparency seems like quite a severe issue for some people, so it would be disappointing if this wasn't possible.

[goddessfreya]

To my knowledge no bug has been filed upstream. I don't know of any workaround. EGL only exposes 65 of the 504 xvisuals supported by my computer, and all of them have alpha == 0 && alphaMask == 0.

[goddessfreya]

https://bugs.freedesktop.org/show_bug.cgi?id=67676

No workaround.

[goddessfreya]

I've been working hard at this issue, but I'm not there yet: https://gentz.rocks/posts/adventures-in-mesa-egl-and-transparency/

[goddessfreya]

https://termbin.com/oy16
https://termbin.com/wj13

I still need to write the appropriate xorg patch to utilize the new EGL extension otherwise some applications not expecting transparency might get it (although that was not the case on my computer), however, beyond that, users interested in testing this out should be able to apply this patch as is with no negative side effects.

[goddessfreya]

As an update: currently the extension is being reviewed. https://bugs.freedesktop.org/show_bug.cgi?id=67676

[goddessfreya]

[goddessfreya]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1185 just merged into mesa! The patch should land in the next stable mesa release. Unfortunately, it got merged one day too late to be included in Mesa 19.2.1 >.<

Expect to see this fixed in Mesa 19.2.2, which releases on 2019-10-23!

[okias]

Since the original MR got reverted, it's fixed in Mesa 24.1.

[kchibisov]

In the current glutin transparency is not blocked on EGL in any way iirc, so it should just work if it got fixed by mesa.