http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #15 from Thaylor Santos <thaylormichi@gmail.com> --- Thanks for both runs. The validation result settles the DXVK question, and the WS_EX_LAYERED null result led to the gate this bug actually hangs on. Line numbers below are from current wine master (8f8792fc85). What decides whether a window gets an alpha-capable visual, in stock Wine: dlls/win32u/window.c, get_window_surface() (2202), lines 2238-2246: is_layered = new_surface && new_surface->alpha_mask; create_opaque = !(get_window_long( hwnd, GWL_EXSTYLE ) & WS_EX_LAYERED); ... else if (!create_opaque && is_layered) create_layered = TRUE; create_layered reaches the driver as the "layered" argument of X11DRV_CreateWindowSurface, and comment 5 already found what it does there: set_window_visual( data, &argb_visual, TRUE ). Where alpha_mask is set: window.c:2777, in NtUserUpdateLayeredWindow: window_surface_set_layered( surface, key, -1, 0xff000000 ); <- nonzero window.c:2268, the SetLayeredWindowAttributes path: window_surface_set_layered( new_surface, key, alpha_bits, 0 ); <- zero UpdateLayeredWindow is the only caller that sets it nonzero. It is also the only one of the five callers of get_window_surface() that passes create_layered=TRUE (window.c:2739, also inside NtUserUpdateLayeredWindow); the other four pass FALSE. So Wine's one route to an alpha visual requires the application to push its pixels through UpdateLayeredWindow, as a GDI bitmap. An application rendering with Direct3D through a client surface has no such bitmap and never calls it, so it cannot reach that path whatever it does with WS_EX_LAYERED or DwmExtendFrameIntoClientArea. That also explains your section 5 result: SetLayeredWindowAttributes(LWA_ALPHA) passes alpha_mask 0, so is_layered stays false and the driver is never asked for an ARGB visual - Depth 24. And it fits the applications in this report: they are visible on screen, so they call SetLayeredWindowAttributes, which is precisely the call that does not get them an alpha visual. As a defect: Wine infers "this window needs an alpha-capable surface" from the drawing method, and has no branch for a window that declares the intent through dwmapi and then draws with a 3D API. The stub is where the intent is dropped. Where it has to arrive is visual selection. Extending this gate is one way, but probably not the right one: create_layered also creates a window surface and turns off direct drawing (enable_direct_drawing() returns FALSE when layered), which is not what a window presenting through a client surface wants. Your own 82084 runs are the evidence - that test window is not WS_EX_LAYERED, never goes near this gate, and is transparent anyway, because the GE patch sets the ARGB visual directly in create_whole_window(). set_window_visual() is already called after window creation elsewhere in winex11 (X11DRV_SystrayDockInsert, window.c: 2983, with use_alpha TRUE), so doing it when the margins arrive looks feasible without disturbing the surface machinery. On your section 5 caveat - I think the shape can be ruled out from the code: const int shape_kind = alpha_mode ? ShapeInput : ShapeBounding; In ALPHA mode the patch sets ShapeInput, which only governs which pixels of an already-rendered window receive pointer events. It cannot make anything transparent or opaque, so those 26 rectangles are the click-through region, not a visual clip, and the ARGB visual carries the transparency in the layered case too. WINE_LAYERED_OVERLAY_SHAPE=0 did not remove the line because the guard is "if (!layered_overlay_shape_enabled() && !alpha_mode) return TRUE;" - with ALPHA=1 it proceeds regardless, maintaining the input region. The variable is WINE_LAYERED_OVERLAY_INPUT_SHAPE=0. Warning if you try it: in GE-Proton11-6 that flag leaves the window taking pointer input over its whole rectangle (fixed in GloriousEggroll/proton-ge-custom#760, merged, not yet released). Harmless for a visual measurement, misleading for an input one. Your VUID-VkSwapchainCreateInfoKHR-compositeAlpha-01280 result is what I suspected in comment 12 and could not show. It also corrects my understanding of my own patch: I wrote that presenter change believing it produced the transparency; what it does is keep the swapchain request inside the advertised set once winex11 has handed out an ARGB visual. Worth carrying into a fix - not the patch, but the fact that giving a window an alpha visual can silently put existing Vulkan clients of that window out of spec on drivers that tolerate it. M1 is correct behaviour rather than a limitation: a layered window is not mapped until SetLayeredWindowAttributes or UpdateLayeredWindow. My request was aimed at the window shape the overlay games use and found the mapping rule instead; section 5 is the run that answered the question, so thanks for adding it. I have requested fork access on the WineHQ Gitlab to work on this. The shape I have in mind follows what SetLayeredWindowAttributes already does: store the requested margins server-side, carry them to win32u, and add the missing branch at the gate above - the drivers need no new capability. I will take you up on the offer to build and test once there is something to try. -- 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.