[PATCH 0/1] MR7551: win32u: Prevent remote drawing to ULW layered window.
Fixes a regression introduced by 309daa5beef262333b8c5328018782401c3380a6 . -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7551
From: Paul Gofman <pgofman(a)codeweavers.com> --- dlls/win32u/window.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/win32u/window.c b/dlls/win32u/window.c index 98e2e46e67d..83494b1ec62 100644 --- a/dlls/win32u/window.c +++ b/dlls/win32u/window.c @@ -2091,7 +2091,7 @@ static BOOL apply_window_pos( HWND hwnd, HWND insert_after, UINT swp_flags, stru extra_rects[0] = extra_rects[1] = new_rects->visible; if (new_surface) { - extra_rects[1] = new_surface->rect; + extra_rects[1] = is_layered ? dummy_surface.rect : new_surface->rect; OffsetRect( &extra_rects[1], new_rects->visible.left, new_rects->visible.top ); } if (valid_rects) extra_rects[2] = valid_rects[0]; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/7551
This fixes Warhammer Vermintide 2 launcher being mostly transparent on start. Commit 309daa5beef262333b8c5328018782401c3380a6 prevented gdi drawing to UpdateLayeredWindow (ULW)-managed layered windows, but only for in-process rendering. In case of other process doing any sort of gdi draw on the layered window or its child that goes through driver's pGetDC and drawing actually succeeds (while not doing the right thing). The said launcher gets the contexts of one of its layered window transparent onscreen because of a child window created in the other process which gets WM_ERASEBACKGROUND and the "background" is successfully erased (made transparent) by the handling in DefWindowProc. Then, UpdateLayeredWindow is not called anymore, and while the game does some drawing on the child window in the same process it goes nowhere after referenced commit (perhaps correctly) and nothing flushes the layered window surface after on-screen whole window was emptied by erase background. With Wine 9 we were ending up with the empty top_rect passed to server (because for layered window X11DRV_WindowPosChanging wasn't ever updating the surface and win32u.apply_window_pos was ending up with the surface rect from default surface). That was providing clipping in the other process (set through update_visible_region) so the blits to user driver's DC weren't changing anything. This patch provides the clipping to the other process gdi rendering the same way it worked earlier, just now it is more explicit with is_layered flag. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7551#note_97515
Sounds like an ugly workaround but it indeed restores some logic that was there before, and I don't think we're anywhere near getting cross-process child of layered windows properly supported. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7551#note_97556
This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7551
participants (3)
-
Paul Gofman -
Paul Gofman (＠gofman)
-
Rémi Bernon