Return error on out of date surface

[cetra3]

I've ran into an issue using Zed in a Tiling WM that it gets stuck in a loop and never resolves itself. This is because there is something invalidating the surface, but not sure what it is exactly. The fix is to, when this happens, reinitialise the surface.

This PR makes the acquire_frame return a Result so the callee can handle this case correctly: VK_ERROR_OUT_OF_DATE_KHR: The swap chain has become incompatible with the surface and can no longer be used for rendering. Usually happens after a window resize, but there seems to be other reasons for it.

[kvark]

Thank you for the PR!
The current implementation intentionally handles the out of date internally. The assumption is that the user has another mechanism of getting the signal of surface being resized (like an event from the window system), and that will make the user to recreate the surface. So "out of date" is essentially ignored, with a warning in the log.
We need to understand why this approach doesn't work for your Tiling WM.

[cetra3]

@kvark how do I check why a surface is out of date without this change & is there any logging/debug I can look at to check why it is going out of date. Essentially if it's not a resize event but another event, the app gets stuck and has no way of fixing it

[cetra3]

How about a new method that returns a Result and this method calls that method internally?

That way the signature is kept the same but we can still get the error out if we want to

[cetra3]

I've adjusted the PR to include a try_acquire_frame method, but keeping the semantics/signature of acquire_frame intact

[kvark]

how do I check why a surface is out of date without this change

With current code, the only error that is not fatal is OUT_OF_DATE, in which case we'd return a "dummy" frame. Admittedly, the user can't know if it's dummy. We could expose a simple method, e.g. is_valid(), for the user to know.

The approach you are suggesting - via try_acquire_frame is fine. The only problem is that it's not platform-agnostic.
We'd either need to define an error type that is platform-agnostic and implement this for other backends, or we add "vulkan" somewhere in the function name to make it clear that this is backend-specific.

[cetra3]

I've adjusted the method to be called vulkan_try_acquire_frame