My engine creates windows on a main thread, and performs all rendering in a second thread. One of my rules is that the engine does not support resizable windows when multithreaded rendering is enabled. However, there is one issue with fullscreen windows. It seems that when a fullscreen window is deselected, it gets minimized, and the window is resized to something like 400x200. This causes vkAcquireNextImageKHR() to return an error, which I then interpret to create a new swap chain.
Problem solved right? I am not sure. Is it safe to use vkAcquireNextImageKHR() in this manner? The window lives on the main thread, and vkAcquireNextImageKHR is being called on the rendering thread. Is this okay to do, or do I need all the window code to live in the rendering thread too?
As stated in the specification, access to the parameters of the function call (except for the VkDevice) must be “externally synchronized”. That is, you cannot concurrently manipulate the same VkSwapchainKHR object from different threads.
I’m not accessing the swap chain from another thread. I am talking about the win32 window handle (HWND) the swap chain is created on. It seems that window resizing is unavoidable under the conditions I described. This function can return VK_ERROR_OUT_OF_DATE_KHR, signifying that the surface has changed size, but is this going to be thread-safe if the window code is all on another thread? I don’t know what the connection between the HWND and the swap chain looks like or what this function is doing internally.
The specification is clear on what must be externally synchronized. Anything outside of that is not the specification’s business. That is, it is the implementation’s job to figure out how the OS-specific window system objects feed the swap chain, not yours.
Just respond to what the swapchain tells you, in accord with the restrictions laid out by the Vulkan spec, and go from there.