http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #10 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Follow-up to comment 8; full measurements attached as plain text. One correction to comment 8 first: I gave the DXVK version as 3.10. That is only how the GE build labels itself; the bundled release is DXVK 3.1 (commit 70d7508c). In comment 8 I said the DXVK half of the GE patch did nothing here. thaylorz asked me to check that properly, so I re-ran my test from comment 5 on both Vulkan drivers in this laptop (NVIDIA 615.71.09 and Mesa 26.2.2 RADV), once with the patched DXVK that GE-Proton11-6 ships and once with the official DXVK 3.1 release: same source commit, no patch, always presents OPAQUE. All twelve runs agree. With WINE_LAYERED_OVERLAY_ALPHA=1 the window gets a 32-bit visual and is fully transparent (0 of 133472 client pixels left black, marker intact); without it, Depth 24 and the usual black box. Removing the DXVK patch changes nothing on either driver. For this bug that narrows it down: the effect comes entirely from winex11 giving the window an ARGB visual, and the Vulkan presenter can stay as it is. A real fix would be dwmapi recording the margins a window asked for and the display driver giving that window an alpha-capable surface. DWM and --no-dwm runs are still identical everywhere, since nothing in Wine reacts to DwmExtendFrameIntoClientArea yet. Advertised compositeAlpha is no use as a check (NVIDIA's X11 surface offers only OPAQUE and is transparent anyway); xwininfo is: Depth 24 means the black box, 32 means the alpha path is live. Limits: a plain WS_OVERLAPPEDWINDOW with d3d9, not a WS_EX_LAYERED overlay game, one machine under KWin via XWayland. I can build and test any proposed fix. -- 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.