https://bugs.kde.org/show_bug.cgi?id=435978
--- Comment #3 from Ethan Lee <flibitijib...@flibitijibibo.com> --- >Note that not a lot compositors properly support surface re-mapping, it might >be a better idea just to re-create the xdg_toplevel surface instead. This got discovered pretty quickly, so that's what we're doing now. HideWindow: https://github.com/libsdl-org/SDL/blob/f1ad942a1175105e4ab7d1cd98b842f84b3bcb2b/src/video/wayland/SDL_waylandwindow.c#L720-L754 ShowWindow: https://github.com/libsdl-org/SDL/blob/f1ad942a1175105e4ab7d1cd98b842f84b3bcb2b/src/video/wayland/SDL_waylandwindow.c#L646-L718 The test case uses FNA (see wltest.cs, which can be compiled with 'csc wltest.cs -r:FNA.dll', and https://github.com/FNA-XNA/FNA/ ), but the Wayland portion is entirely within SDL itself. To compile SDL you can grab the dependencies for your system (i.e. dnf builddep SDL2), then do a plain './configure && make' with the latest Git revision. How this test works is that it starts with a visible window, which is then not touched in any way other than with either eglSwapBuffers or vkQueuePresentKHR. When pressing space, it calls HideWindow and keeps a timestamp, then after three seconds have passed it calls ShowWindow. No other interactions with the window are being made. Where this bug might be troublesome is for Vulkan contexts - if I'm understanding correctly, what we're doing with surfaces is correct (though I am aware of wl_surface, xdg_surface, and VkSurfaceKHR, so I randomly chose xdg_surface here), but what we're doing with buffers is not (of which we do not reference that type at all, but based on the log I am guessing these are the Vulkan swapchain images). The big problem is that the Vulkan swapchain is totally separate from the SDL Wayland window, and if I'm understanding this correctly it sounds like destroying the xdg objects also destroy/invalidate the buffers, in which case I would expect vkAcquireNextImageKHR to return something like VK_ERROR_OUT_OF_DATE_KHR, so that we can recreate the swapchain with new buffers that are valid for the unmapped/remapped surface. The Vulkan context has no other way of knowing that the window surface has changed in a way that swapchain recreation is necessary. And as a reminder: OpenGL/EGL are okay with this, and if I just use mailbox or immediate presentation instead, the program runs as expected (which also seems to point to there being a gap in how swapchains are treated when this happens). -- You are receiving this mail because: You are watching all bug changes.
