Correctly handle vk::Result::eOutOfDate from vk::raii::SwapchainKHR::acquireNextImage and vk::raii::Queue::presentKHR

[asuessenbach]

vk::Result::eOutOfDate is an error code for vk::[raii::]SwapchainKRH::acquireNextImage and vk::[raii::]Queue::presentKHR.
That is, as long as VULKAN_HPP_RAII_NO_EXCEPTIONS is not defined, they throw an exception on such a result.
In order to catch that error, you have to use the try-catch-idiom.

As usual, if this is considered to be ok, I can carry that change over to the other chapters.

Note 1: I don't know how to enforce a vk::Result::eOutOfDate error from any of those two functions. That is, I could not really test the error handling.

Note 2: We could as well wait for and require the next VulkanSDK and define VULKAN_HPP_HANDLE_ERROR_OUT_OF_DATE_AS_SUCCESS, keeping the source as it is (maybe with some additional comments).

[SaschaWillems]

I'd prefer option 2, see #220

Forcing out of date on desktop is afaik not (easily) possible, unless you have a tablet that supports orientation changes. Should be easy to test though on Android.

[asuessenbach]

Now that 1.4.335 is out, which includes that VULKAN_HPP_HANDLE_ERROR_OUT_OF_DATE_AS_SUCCESS, we can use it here.

Should we now just require at least that version and assume VULKAN_HPP_HANDLE_ERROR_OUT_OF_DATE_AS_SUCCESS is defined, or should we have some compile-time check to either use eOutOfDate as a success code or as an error code?

[marty-johnson59]

HI @asuessenbach, we discussed this on the docs call. Let's go with Option 2. LMK when that's been adjusted and we'll merge. Thanks!

[asuessenbach]

Let's go with Option 2

Ok, done.
But I don't know how to resolve the CI failures on ubuntu and windows. Any help would be appreciated.

[gpx1000]

I'm working on it.

[SaschaWillems]

Seeing almost the exact same CI failures for me PR. Looks like some issue with CI caching, see #254

[gpx1000]

That actually feels like a much better solution. Thanks!

[asuessenbach]

I noticed a couple of issues with some of the chapters (with and without my changes):

18: lots of VVL validation messages on vkCmdDraw
22: crash in vkCmdDrawIndexed
26: VVL performance warning
37: black window

[asuessenbach]

@gpx1000 Now that this PR is complete, please have a look at it again.

[SaschaWillems]

18: lots of VVL validation messages on vkCmdDraw

See #102

22: crash in vkCmdDrawIndexed

I don't get a crash, but a black window instead. When enabling validation, I get errors about the descriptor set never being bound. But I think that's intentional, it's the chapter BEFORE descriptor sets are introduced. Might be a good idea to disable drawing though, to avoid potential crashes.

37: black window

Works fine for me.

[SaschaWillems]

Code changes look good, but documentation also needs to be adjusted. See e.g. the swap chain recreation chapter.