On Wed Nov 8 23:51:27 2023 +0000, Rémi Bernon wrote:
Fwiw, something to keep in mind, if not necessarily something to take into account now, as winex11 has the same issue: Proton work showed us that multiple vulkan surfaces may be created for the same window, possibly outliving it. Only one is active at a time, but we had to decouple the windowing data from the vulkan client surfaces. Instead we keep the vulkan surfaces and their X11 window live in a vulkan-specific list, reparenting them with their windows as they become active or inactive. At the very least, I don't think we should return the client surface twice, when creating different win32 surfaces.
The proposed design is based on the following assumptions (which are what the Vulkan spec mandates, AFAIU):
1. We can have multiple VkSurfaceKHRs for the same HWND 2. We can have only one (non-retired) VkSwapchainKHR for a HWND (i.e., otherwise we get VK_ERROR_NATIVE_WINDOW_IN_USE_KHR) 3. The HWND may be destroyed while associated VkSurfaceKHRs are still around (which eventually leads to VK_ERROR_SURFACE_LOST_KHR).
Each `wayland_client_surface` may be associated with (but not owned by) a `wayland_surface`, and is implemented as a `wl_subsurface` of that associated parent `wl_surface`. The `wayland_client_surface` is owned collectively (e.g., through refcount) by the VkSurfaceKHRs only. When a HWND (and thus `wayland_surface`) is destroyed, any `wayland_client_surface` continues to live on as long as there are VkSurfaceKHRs targeting it, but it's not visible anymore since the parent `wl_surface` of the client `wl_subsurface` is now gone. In part 10.2 I will also emit VK_ERROR_SURFACE_LOST_KHR for such cases. The swapchain attaches and commits buffers to the subsurface from `wayland_client_surface`.
If I haven't misunderstood your concern, I think this design should cover the case you mentioned. Has some other aspect of the described behavior proved to be problematic in Proton?