http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #8 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 81985 --> http://bugs.winehq.org/attachment.cgi?id=81985 GE-Proton11-6: no env var, ALPHA=1 over the desktop, and ALPHA=1 vs the --no-dwm control Thanks for the pointer, bczhc0 - I would not have found that one on my own. Both links in comment 7 land on the same file, so for anyone else reading: the patch is by thaylorz, GloriousEggroll/proton-ge-custom PRs #553 / #555 / #556 / #716, built on Solarisfire's original XShape idea from ValveSoftware/Proton#9841. I ran my own test from comment 5 against GE-Proton11-6 (wine-staging 11.0), which ships it. Separate prefix, DXVK d3d9 3.10, Plasma 6.7.4 Wayland, XWayland, same method as before - picture behind the window, crop the client rect, count differing pixels. no env var xwininfo Depth: 24, still the black box, and the DWM run and the --no-dwm control are pixel-identical (0 differing pixels) ..._ALPHA=1 Depth: 32, and the client area now matches the bare desktop behind it: 388 of 140456 pixels differ across the client minus the opaque marker, and those 388 are the one-pixel window edge So the transparency itself is real, no argument there. But the --no-dwm control under ALPHA=1 is pixel-identical to the DWM run too (0 differing pixels). The patch never asks whether the app called DwmExtendFrameIntoClientArea - dwmapi is untouched and still the stub returning S_OK. It only edits winex11.drv (x11drv.h, init.c, window.c) plus a DXVK presenter patch, and the env var hands the ARGB visual to every window in the process. The DXVK half did nothing here: "compositeAlpha -> 1 (surface supports 1)", the X11 surface only offers OPAQUE, so all of the effect comes from the ARGB visual in winex11. ..._SHAPE=1 alone changed nothing on my test (20 pixels of frame antialiasing) - that path wants WS_EX_LAYERED, and a layered window that never calls UpdateLayeredWindow is invisible anyway, so I could not exercise it. Which is why I read it as a game patch rather than a fix for this bug: it proves the mechanism works, but it is a per-process switch, and the missing piece is still dwmapi telling winex11 that a window asked for glass. thaylorz, if you are reading - is any of this meant for wine-devel, and would you rather send it yourself? I am not going to carry someone else's patch upstream under my name without asking first. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.