On Thu Nov 9 09:14:13 2023 +0000, Alexandros Frantzis wrote:
The proposed design is based on the following assumptions (which are what the Vulkan spec mandates, AFAIU):
- We can have multiple VkSurfaceKHRs for the same HWND
- 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?
Well, I don't know for sure anymore. I believe we had issues when using a single client window. This isn't necessarily a blocker because right now upstream winex11 has the same kind of issues.