http://bugs.winehq.org/show_bug.cgi?id=52254 Thaylor Santos <thaylormichi@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thaylormichi@gmail.com --- Comment #12 from Thaylor Santos <thaylormichi@gmail.com> --- I am the author of the GE-Proton layered-overlay patch that comments 7 and 8 point at. Thanks to bczhc0 for the pointer and to wehrwolfmann for measuring it properly rather than taking my word for it - attachment 82084 is more rigorous than anything I produced for that patch. Agreeing with comment 10 first, since it saves whoever implements this some work: the Vulkan presenter change in my patch is not what produces the transparency. The ARGB visual that winex11 gives the window is. A fix for this bug does not need to touch DXVK, vkd3d-proton or any other presenter. One thing from attachment 82084 that I think deserves more weight than the "Limits" section gives it, because it is a consequence of the fix rather than of my patch: Section 5.4 shows that on Mesa the advertised compositeAlpha set depends on the window's visual. RADV's xcb/xlib surface reports OPAQUE|INHERIT (9) on a normal 24-bit window, but PRE_MULTIPLIED|INHERIT (10) on the 32-bit ARGB window - OPAQUE is no longer in the set. VkSwapchainCreateInfoKHR requires compositeAlpha to be one of the bits in supportedCompositeAlpha. So the moment a window is given an alpha-capable visual, an application (or translation layer) that still asks for OPAQUE is asking for a bit outside the advertised set. In the section 6.2 controls RADV created the swapchain anyway; that is driver tolerance, and the validation layers were not run. This is not an argument for keeping my presenter patch. It is a property any fix here inherits: handing a window an ARGB visual changes what its Vulkan surface advertises, and existing clients of that window may then be making an invalid swapchain request. Worth knowing before it surfaces as a driver-specific bug somewhere else. A gap in the coverage, which is mine rather than wehrwolfmann's: my patch also forces offscreen rendering for WS_EX_LAYERED windows when it is enabled, so a layered overlay window and the plain WS_OVERLAPPEDWINDOW in attachment 81972 do not take the same path through winex11. All of the measurements so far are on the non-layered path. The applications this bug is about - the Unity desktop overlay in comment 0, the widget-style games in comment 4, TBH: Task Bar Hero - are layered windows drawing through a 3D client surface, so a fix should be checked against that case and not only against the plain window. On the shape of a fix, from having spent a while in this code: comment 5 already identified the relevant place, X11DRV_CreateWindowSurface in dlls/winex11.drv/ bitblt.c, where the ARGB visual is only selected inside the "if (layered)" branch, i.e. for WS_EX_LAYERED plus UpdateLayeredWindow. DwmExtendFrameIntoClientArea in dlls/dwmapi/dwmapi_main.c is a stub that records nothing, so there is no state to consult and no channel to carry it - dwmapi currently imports user32 and nothing else. The missing pieces are that state and that channel, not a new capability in the driver: winex11 already knows how to put a window on an alpha visual. Whatever carries it should reach winewayland.drv too, since comment 5 shows the same black window there. Finally, so it is not mistaken for something it is not: the GE patch is a per-game workaround, not a fix for this bug. It is opt-in through an environment variable that applies to every window in the process, it never asks whether the application called DwmExtendFrameIntoClientArea, and the DWM and --no-dwm runs are identical under it - which attachment 82084 measures directly. It makes the affected games playable today. It should not be read as closing this report. wehrwolfmann - the one-line variant that would close the coverage gap above is adding WS_EX_LAYERED to the CreateWindowExA call in attachment 81972, without calling UpdateLayeredWindow, which is the shape these applications actually use. No obligation; you have already done more measuring here than I have. And a validation layer run on the section 6.2 stock/RADV control would settle the compositeAlpha point in one line. -- 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.