That is, in particular, needed for Disgaea 5 complete to render movies with 'MovieType=1' settings (that settings is auto selected initially by the game based on GPU). Movie render window is initially a top level window, then the game reparents movie rendering window to the main window with SetParent() after 3d rendering to game window was already initialized earlier. The offscreen state for the window being rendered to (child in this case) is updated during presentation, but the parent does not (the same issue would be for the things going other way around, presenting to parent window when the child is never presented after reparenting).
This part is not enough to fix these cases though since the recent commit 786d9d1685ac220081b10cc779d4d331ddd2fc52 . When parent is not presented but the child is, the child image should appear in the window regardless of the fact that the parent has no WS_CLIPCHILDREN attribute. I know that commit is fixing regression Bug 57503, but due to these reasons the commit doesn't look right. And it is not clear to me from bug description what was actually wrong with "World in conflict" rendering when parent window offscreening took place: that alone is not supposed to be breaking the rendering (and if it would that would probably be a blocker for implementing child windows the way they are implemented?), I suspect there might be a bug elsewhere (just e. g., some other missing case of synchronizing window config state which ends up in child window not being properly offscreened in that case).
From: Paul Gofman pgofman@codeweavers.com
--- dlls/win32u/ntuser_private.h | 1 + dlls/win32u/vulkan.c | 12 ++++++++++++ dlls/win32u/window.c | 14 ++++++++++++++ 3 files changed, 27 insertions(+)
diff --git a/dlls/win32u/ntuser_private.h b/dlls/win32u/ntuser_private.h index 2f3bbdf91c0..0d5f4430324 100644 --- a/dlls/win32u/ntuser_private.h +++ b/dlls/win32u/ntuser_private.h @@ -228,6 +228,7 @@ extern PFN_vkGetInstanceProcAddr p_vkGetInstanceProcAddr;
extern BOOL vulkan_init(void); extern void vulkan_detach_surfaces( struct list *surfaces ); +extern void vulkan_update_surfaces( struct list *surfaces );
/* window.c */ HANDLE alloc_user_handle( struct user_object *ptr, unsigned int type ); diff --git a/dlls/win32u/vulkan.c b/dlls/win32u/vulkan.c index c676ae10e54..77e3015199d 100644 --- a/dlls/win32u/vulkan.c +++ b/dlls/win32u/vulkan.c @@ -705,12 +705,24 @@ void vulkan_detach_surfaces( struct list *surfaces ) } }
+void vulkan_update_surfaces( struct list *surfaces ) +{ + struct surface *surface; + + LIST_FOR_EACH_ENTRY( surface, surfaces, struct surface, entry ) + driver_funcs->p_vulkan_surface_update( surface->hwnd, surface->driver_private ); +} + #else /* SONAME_LIBVULKAN */
void vulkan_detach_surfaces( struct list *surfaces ) { }
+void vulkan_update_surfaces( struct list *surfaces ) +{ +} + static void vulkan_init_once(void) { ERR( "Wine was built without Vulkan support.\n" ); diff --git a/dlls/win32u/window.c b/dlls/win32u/window.c index 4855555d926..59d0c4b7cb1 100644 --- a/dlls/win32u/window.c +++ b/dlls/win32u/window.c @@ -477,6 +477,20 @@ HWND WINAPI NtUserSetParent( HWND hwnd, HWND parent ) if (was_visible) NtUserShowWindow( hwnd, SW_SHOW );
set_thread_dpi_awareness_context( context ); + + win = get_win_ptr( hwnd ); + if (win && win != WND_OTHER_PROCESS && win != WND_DESKTOP) + { + vulkan_update_surfaces( &win->vulkan_surfaces ); + release_win_ptr( win ); + } + win = get_win_ptr( parent ); + if (win && win != WND_OTHER_PROCESS && win != WND_DESKTOP) + { + vulkan_update_surfaces( &win->vulkan_surfaces ); + release_win_ptr( win ); + } + return old_parent; }
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=150408
Your paranoid android.
=== debian11b (64 bit WoW report) ===
mf: mf.c:6276: Test failed: Unexpected hr 0.
To elaborate a bit more about https://gitlab.winehq.org/wine/wine/-/commit/786d9d1685ac220081b10cc779d4d33... issue, its negative effect looks broader than the mentioned specific game behaviour. The fact the child windows are not clipped hints us nothing really about the possibility to bypass "offscreening" of parent's window client window. The most basic and common way to draw on a window which has an unclipped child is to draw parent (e. g., on WM_PAINT) and then update child on WM_PAINT it will receive after. Bypassing offscreening of the parent won't allow child image to appear regardless of whether it is used Vulkan or gdi rendering.
Another possibility (relatively common for d3d version < 10) for Bug 57503 is, if the child window is actually present, already offscreen but is getting correctly clipped, is that maybe it uses d3d rendering in exclusive fullscreen mode which is supposed to draw on top of everything (including even clipped child windows or sibling top level windows above in Z order) and while clipping child windows may be ecen correct from the point of view of Vulkan rendering that started behaving worse with d3d. The same happened when GL child window clipping was introduced (and those regressions are still there). Getting rid of child window clipping without implementing exclusive fullscreen, while helps in some cases, breaks other and in the view of d3d exclusive fullscreen support doesn't fix the problem completely as doesn't help against hindering by siblings top level windows (we have some bugs with such cases too).
There are indeed various things to tweak for offscreen vulkan surfaces rendering but I don't think they are strictly speaking regressions, so maybe not worth the risk?
I also don't think we should call into the drivers with the user lock held and instead maybe something like https://gitlab.winehq.org/wine/wine/-/merge_requests/7045.
On Thu Dec 19 15:51:31 2024 +0000, Rémi Bernon wrote:
There are indeed various things to tweak for offscreen vulkan surfaces rendering but I don't think they are strictly speaking regressions, so maybe not worth the risk? I also don't think we should call into the drivers with the user lock held and instead maybe something like https://gitlab.winehq.org/wine/wine/-/merge_requests/7045.
That is not regressions from 9.0 but a regression from earlier development versions. Of course if we have to choose regressions from 9.0 are more important but do we?
Yes, https://gitlab.winehq.org/wine/wine/-/merge_requests/7045/diffs?commit_id=83... should probably do the same, closing this.
This merge request was closed by Paul Gofman.
-
Marvin -
Paul Gofman -
Paul Gofman (＠gofman)
-
Rémi Bernon (＠rbernon)