WGL backend supports_transparency is false

[godlikedh]

Hello!

I attempted to create a transparent window using egui, but it was not transparent. After investigating further, I discovered that the issue stems from the finalize_window (https://github.com/rust-windowing/glutin/blob/master/glutin-winit/src/lib.rs#L194) function. The supports_transparency method returns false for me. Upon additional research, it appears that the wgl_extra::TRANSPARENT_ARB attribute is consistently false on my setup, which seems odd given that I have a modern discrete GPU with up-to-date drivers. And this attribute is false on windows, compiling and running same code under WSL ubuntu makes this attribute True.

Moreover, the Glutin window example is transparent since the finalize_window function is never called for it. I'm wondering if it's safe to remove this check entirely and proceed without it. According to the Winit code, it creates transparent windows without performing any compatibility checks. So, I'm confused about why Glutin modifies this behavior.

Could someone clarify this for me or suggest a solution?

[kchibisov]

Moreover, the Glutin window example is transparent since the finalize_window function is never called for it

it's called. https://github.com/rust-windowing/glutin/blob/master/glutin_examples/src/lib.rs#L86

nvm, it's actually not called for wgl, because of how wgl weirdly works, there's also no way you can finalize a window with WGL though, since you must create window before creating everything else, so only further configs will work for extra windows, but not the first one.

[kchibisov]

glutin does't modify anything and only adjusts the transparency in winit integration to account for transparency of the config, since it does affect the way it all works on other platforms. If you draw opaque content it can do optimization resulting in overall better performance, when transparency is disabled.

The point with alpha is that if there's no alpha how would you draw a transparent window, etc? It still may work sometimes on some systems, but generally not.

[godlikedh]

I apologize for any misunderstanding. I was trying to say that Glutin sets transparency to false if the config supports_transparency() is false.

The issue I'm facing is that I need a transparent window, but I can't achieve this because the finalize_window function is called in eframe, and within this function, transparency is set to false. My system is definitely capable of rendering transparent windows, but I'm not sure how to debug why GetPixelFormatAttribivARB(TRANSPARENT_ARB) returns false on my system (for all pixel formats). I would appreciate any workarounds or solutions for this problem.

[kchibisov]

What I said before is that finalize_window can not be called on WGL (Windows) in a sane case and it's not called in example because Window must be created up front, thus it's not possible to alter it, unless you create extra windows.

Please, inspect transparency support inside the example and whether it's really false for you for all the configs out there.

[godlikedh]

https://pastebin.com/Vwwq78z4
Yes, it's false for all the configs, even if i request for all avaialble pixel_formats with empty attrs in ChoosePixelFormatARB. It's still false for each of them

[kchibisov]

@godlikedh well, glutin-winit just suggests on how to handle things, since it doesn't limit glutin in any way. If you think that transparency works in certain setups, then I guess you can assume so. I've also state again, that on windows in a correct handling, you won't end up in finilize_window path no matter what you do though, unless you open a extra window with the existing config. So ensure that your window is created before display, otherwise config loading will break and you'll load something arbitrary from generic driver. Basically the way glutin example does, though, given that you've said that in glutin-example you have false for everything, then I guess it's not an issue for you and you've done things correctly.

For reference on other platforms finilize is needed to avoid rendering issues when you draw transparent surface into opaque window.

It could also always be just a bug in the driver, which are quite common... Maybe there're other means to detect transparency support or maybe it should be assumed to be always true these days, and we can somehow flip the handling, but I'll leave it up to someone who understands. I wonder what e.g. SDL2 does and whether it checks for transparency that way.

In anyway, you're free to tune code however you want, glutin just lists whatever is present. I've also expected egui to use things directly and not depend on glutin-winit though, so they can tune it more to their liking, since glutin-winit is a generic crate showing how handling should generally work.

[godlikedh]

@kchibisov
Hello!
Guy from AMD said they just don't support this attribute for "normal" GPUs
GPUOpen-Drivers/AMD-Gfx-Drivers#29

maybe wgl_backend supports_transparency function should be changed to something else? or maybe just return true? or maybe check GPU if it is and AMD?

[kchibisov]

If they don't support, then they should return an error instead instead of not working? It just doesn't make any sense tbh.

I'm also not sure how to check driver used with just wgl alone.

[MarijnS95]

Yes, it's false for all the configs, even if i request for all avaialble pixel_formats with empty attrs in ChoosePixelFormatARB. It's still false for each of them

Note that WGL_ARB_pixel_format appears to be designed to ignore this flag in ChoosePixelFormatARB (when compared to WGL_EXT_pixel_format):

• wglChoosePixelFormatARB now ignores the following attributes (in addition to WGL_NUMBER_PIXEL_FORMATS_ARB): WGL_SHIFT_ARB, WGL_TRANSPARENT_ARB, WGL_TRANSPARENT_VALUE_ARB.