[Bug 52254] New: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)
https://bugs.winehq.org/show_bug.cgi?id=52254 Bug ID: 52254 Summary: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea) Product: Wine Version: 7.0-rc2 Hardware: x86-64 URL: https://zerofield.net/2020/09/30/hajimari-no-kiseki-sp readsheet-translation/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)winehq.org Reporter: johnny(a)localmomentum.net Distribution: --- Created attachment 71376 --> https://bugs.winehq.org/attachment.cgi?id=71376 ColdSteelSubs transparency code (currently not in the distributed application) This application provides a transparent clickthrough overlay to show English translations on top of the original Japanese source. It relies on layered windows and DwmExtendFrameIntoClientArea to handle the transparent display. Currently, the main UI elements show, but the game (or any other application) does not show through. This seems to be because DwmExtendFrameIntoClientArea is only a stub. I'm not sure if that's the only reason it's not transparent, but it's at least one of the reasons. The program itself uses the unity3d engine along with some native dll calls to the relevant user32 apis to handle the transparency. I was able to get a copy of the relevant code (but not the whole application), of which I will attach. Since I can't get all of the code, I've been using an unity sample application to try to figure out some parts myself (the relevant code is here https://github.com/pheonise/Unity3D-Desktop-Overlay/blob/master/Assets/Scrip...). This unity3d application works as expected on windows, but is not transparent via wine (as expected). When i comment the call to DwmExtendFrameIntoClientArea, then it its also no longer transparent on windows as well. It seems that if the sample application works, then I can make sure the dev applies to the same technique to the overlay application. Please let me know If i can provide any more information. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #1 from Johnny Robeson <johnny(a)localmomentum.net> --- I've built the desktop overlay application and uploaded it here: https://www.dropbox.com/s/mi1g5nlif3hhsq8/Unity3D-Desktop-Overlay.tar.gz -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #2 from Johnny Robeson <johnny(a)localmomentum.net> --- Created attachment 71378 --> https://bugs.winehq.org/attachment.cgi?id=71378 simple win32 application that uses DwmExtendFrameIntoClientArea I'm not sure how helpful this is, but i attached simple example of a win32 application hat uses DwmExtendFrameIntoClientArea and almost nothing else. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #3 from Johnny Robeson <johnny(a)localmomentum.net> --- Sorry, i realized i didn't mention that the application itself is free to use and does not require the game to run. You can just download it and run the executable. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 Joel Holdsworth <joel(a)airwebreathe.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joel(a)airwebreathe.org.uk -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 Zhai Can <bczhc0@126.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bczhc0@126.com --- Comment #4 from Zhai Can <bczhc0@126.com> --- DwmExtendFrameIntoClientArea is still a stub in Wine 11.7. Many desktop-widget or desktop-placement genre games require this api to render a transparent window but now they all show as black :(. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 Wehrwolfmann <wehrwolfmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wehrwolfmann@gmail.com --- Comment #5 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 81972 --> http://bugs.winehq.org/attachment.cgi?id=81972 minimal d3d9 + DwmExtendFrameIntoClientArea test (--no-dwm gives the control run) Still a stub on wine-11.16. Comment 4 is right that these windows come out black - I wrote a smaller test than attachment 71378 to pin down where it actually breaks, so I am adding it here instead of filing a duplicate. Attached test, ~75 lines, d3d9 + dwmapi and nothing else: a plain WS_OVERLAPPEDWINDOW, DwmExtendFrameIntoClientArea() with MARGINS {-1,-1,-1,-1} (the documented "sheet of glass"), then a windowed D3D9Ex device with an A8R8G8B8 back buffer. Every frame it clears the client area to ARGB(0,0,0,0) and a 100x100 square in the middle to opaque green. --no-dwm skips the DWM call and changes nothing else - that is the control run. Per MSDN ("Custom Window Frame Using DWM") the extended frame shows wherever the underlying pixels have alpha 0, so the DWM run should be a green square floating over the desktop and the control run an ordinary opaque window. I have no Windows box here, so that half is what the docs say, not something I measured. On Wine the two runs are pixel-identical. I put a colourful picture behind the window; cropping the client rect out of both screenshots, compare -metric AE gives 0. Both are a solid black client area with the green square in it. dwmapi logs the stub and returns S_OK, so the app is told transparency is on, but xwininfo reports Depth: 24 on the X window even though the server advertises 32-bit visuals - there is no alpha channel to composite at all. winex11.drv only moves a window to argb_visual inside the "if (layered)" branch of X11DRV_CreateWindowSurface (dlls/winex11.drv/bitblt.c). Same black window under winewayland.drv, so this is not an X11-only thing. Build: x86_64-w64-mingw32-gcc dwm_alpha.c -o dwm_alpha.exe -ld3d9 -ldwmapi -lgdi32 Tested on wine-11.16 64-bit, clean prefix, winex11.drv on XWayland and winewayland.drv, Plasma 6.7.4 Wayland session, Mesa on NVIDIA. Besides the games in comment 4: desktop mascot apps built on the UniWindowController package take this same path and never call UpdateLayeredWindow, so they all draw as black boxes too. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #6 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 81973 --> http://bugs.winehq.org/attachment.cgi?id=81973 three runs on wine-11.16: DWM path and --no-dwm control (winex11.drv), plus the DWM path under winewayland.drv - all three identical -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 Wehrwolfmann <wehrwolfmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81972|text/x-csrc |text/plain mime type| | -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #7 from Zhai Can <bczhc0@126.com> --- For the info the latest proton-ge has added a [patch] to winex11 so that the transparency can be displayed correctly, including the input region being handled correctly ([pr]). However it's only for winex11 and is implemented using top-level windows with XShape so it requires the xwayland server to handle them well (for example i tested with `kwin_wayland --xwayland` it works but for niri+xwayland-satellite the input-passthrough is still not working) [patch]: https://github.com/GloriousEggroll/proton-ge-custom/blob/53ed6068a99b68f12f6... [pr]: https://github.com/GloriousEggroll/proton-ge-custom/blob/53ed6068a99b68f12f6... -- 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.
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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #9 from Zhai Can <bczhc0@126.com> ---
the patch is by thaylorz, GloriousEggroll/proton-ge-custom PRs #553 / #555 / #556 / #716, built on
yea yea copy-paste typo. I meant [pr] https://github.com/GloriousEggroll/proton-ge-custom/pull/556
thaylorz, if you are reading -
Hmm. May be worth asking them then. Also looking forward this can go in upstream and then when this feature is implemented winewayland can start catching up with it. -- 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.
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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #11 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 82084 --> http://bugs.winehq.org/attachment.cgi?id=82084 ▎ Full measurement log: layered-overlay transparency on NVIDIA and RADV, patched vs stock DXVK 3.1 -- 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.
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.
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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #14 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 82086 --> http://bugs.winehq.org/attachment.cgi?id=82086 Layered-window follow-up: WS_EX_LAYERED variant of 81972 and validation-layer run of the stock DXVK 3.1 / RADV control -- 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.
http://bugs.winehq.org/show_bug.cgi?id=52254 Wehrwolfmann <wehrwolfmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #82084|▎ Full measurement log: |Full measurement log: description|layered-overlay |layered-overlay |transparency on NVIDIA and |transparency on NVIDIA and |RADV, patched vs stock DXVK |RADV, patched vs stock DXVK |3.1 |3.1 -- 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.
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.
http://bugs.winehq.org/show_bug.cgi?id=52254 --- Comment #16 from Wehrwolfmann <wehrwolfmann@gmail.com> --- For thaylormichi, in case it saves duplicate work: MR !10180 (https://gitlab.winehq.org/wine/wine/-/merge_requests/10180, by namoninja, open since February) implements this end to end. It plumbs the DwmExtendFrameIntoClientArea margins from dwmapi through win32u to the drivers, upgrades an existing X11 window to a 32-bit ARGB visual when the request arrives, and invalidates Vulkan swapchains with VK_ERROR_OUT_OF_DATE_KHR so a client that set up before the margins gets a new one. That last part is the compositeAlpha problem from comment #14. It is large (28 files, X11 and Wayland together), currently conflicts with master, and the author describes it as a proof of concept for someone to take over. A small X11-only series along the lines of comment #15 could probably use it as a reference. -- 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.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla