I'm not completely sure about the mechanism, but I think it's simple enough to consider having that upstream now. This shows at least how we can leverage win32u surface changes to decide to switch surfaces on/off-screen and fallback to manual blitting.
Having the surfaces on-screen makes sure they are presented as efficiently as possible, having them off-screen we use GDI blit to indirectly call XCopyArea and this will be suboptimal, probably with visible tearing, but hopefully not too common.
--
v2: win32u: Use GDI blit to implement partial or other process presentation.
winex11: Return an offscreen HDC from vulkan_surface_detach.
win32u: Pass a HDC parameter to vulkan_surface_detach.
winex11: Create a window surface even when there is client window.
winex11: Also attach child client windows to their toplevel window.
win32u: Make sure vulkan windows have a pixel format selected.
win32u: Detach vulkan surfaces that aren't fully visible.
win32u: Detach vulkan surfaces that are offscreen or for another process.
win32u: Move vulkan surfaces to their new parent when reparenting.
win32u: Introduce a new vulkan offscreen surfaces list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
Reduces the time needed to write them from 20ms to 2ms and to read them from 10ms to 1ms, as well as reducing the number of wineserver requests by a lot.
--
v2: win32u: Read / write source modes as a single registry blob.
winex11: Only request display modes driver data when needed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5579