Virtualizing the swapchain is the better and more general plan and something we'd need to do for Wayland cross-process rendering anyway. Implementing composition on the win32u level will take care of it in a generic way, though we probably want to keep the direct rendering path as a default and best option.
This current approach is a best effort with what we have right now, it unlocks various applications which required VK child window rendering, and is cheap enough and doesn't introduce much problems as it simply does the same as GL.
Both GL and VK would then be addressed the same way for composition, through dma-buf export (or the equivalent macOS primitive) and shared resources.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82704
> > VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.
>
> That's unfortunate, I was thinking VK_KHR_present_wait will solve these problems (which are real WRT games too in some cases) until we have a "direct composition" implementation. Are you sure that this is supposed and actual behaviour?
It's the spec behaviour, actually. I didn't test whether it works in practice, and it's not unlikely that it does work in practice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82702
> VK_KHR_present_wait isn't equivalent, because it signals the event on first pixel out, which is too soon.
That's unfortunate, I was thinking VK_KHR_present_wait will solve these problems (which are real WRT games too in some cases) until we have a "direct composition" implementation. Are you sure that this is supposed and actual behaviour?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6467#note_82701