http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #13 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Both measurements done, details in the attached addendum. 1) 81972 test with WS_EX_LAYERED added to CreateWindowExA, no UpdateLayeredWindow, same matrix as 82084 (GE and stock DXVK 3.1, NVIDIA and RADV, DWM and --no-dwm). In all 12 runs the window never shows up: winex11 logs "is layered, delaying mapping", xwininfo says IsUnMapped. Depth still follows the env var (32 with ALPHA=1, 24 without), the client surface still gets the ARGB visual via x11drv_client_surface_create, and compositeAlpha is picked as before (NVIDIA 1 of 1, RADV 2 of 10), but the window is never mapped. X11DRV_UpdateLayeredWindow is never called. As an extra test I added SetLayeredWindowAttributes(255, LWA_ALPHA), GE only: then it maps and behaves like the plain case, transparent with ALPHA=1 on both drivers, black box without. Caveat: in that run the patch also puts a 26-rectangle shape on the window (WINE_LAYERED_OVERLAY_SHAPE=0 did not remove it), so this run does not separate the visual from the shape. 2) Validation layer (load confirmed with VK_LOADER_DEBUG=layer), RADV, ARGB window: stock DXVK 3.1 gets VUID-VkSwapchainCreateInfoKHR-compositeAlpha-01280 ("OPAQUE is not supported, support values are: PRE_MULTIPLIED, INHERIT"). The GE build gives no messages. RADV still creates the stock swapchain and the window is still transparent. So the DXVK part does not make the window transparent, but on Mesa it keeps the swapchain valid once winex11 hands out an ARGB visual. A layered window also needs SetLayeredWindowAttributes or UpdateLayeredWindow before winex11 maps it - which matches what MSDN documents for Windows (not measured there), so the real applications must be calling one of the two. -- 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.