Handle window resizing

[FunMiles]

I've started making use of Vookoo in my own project (so far I had only played on making all the examples work on all my machines) and discovered that there is no support for handling window resize in the vku_framework.

I can get started on this but need a recommendation. @andy-thomason, should this be done within the vku::Window or should the existing vku::Window have its destructor called and a new one rebuilt from scratch? I do not have a feel for how light/heavy everything related to creation/destruction of the window is. It seems fairly heavy, yet Vulkan's swapchain recreation is not light to start with. Clearly the destructor/constructor approach is probably easier to implement but if it does a lot of extra work, it may cause stuttering in resize.

In my own project, I had separated the swapchain as an object that handles the framebuffers and handled the whole recreation within an abstraction of my window/surface. Here, those roles are the Window's domain and I could try to do the minimum work within it. My work previously within Qt toolkit is stutter free.

[FunMiles]

I have taken the approach of just recreating the minimum within the vku::Window. Everything is working but I am getting a few validation layer messages.

Another issue I know can (and given Murphy's law, I'm sure it will on somebody's system) is that I trigger the resize change by catching the exception thrown by the presentQueue method. I think it is not strictly required that an implementation throw this exception. Every time the window is resized I recreate:

• the swap chain
• the images
• the depth stencil
• the frame buffers.

As for the user's program, it is expected to recreate any affected pipelines.

For those who want to check it out, the current state is at https://github.com/FunMiles/Vookoo/tree/resize

For the moment, only the teapot example does the correct pipeline re-creation. Edit: All demos work without crashing. The first 3 are not recreating a pipeline with the right size yet.

[FunMiles]

There is a slight difficulty with the static commands. I've fixed the issue for the texture example. The static drawing build function (functor passed to setStaticCommands) needs to rebuild the pipeline and command buffers any time the window size is changed. I've made a copy of the std::function being passed. But of course all the variables in the functions need to stay in scope. With a capturing by reference lambda, this can yield to some potential errors and crashes.

[andy-thomason]

I'm please to see that this is working much better now. It is very hard to diagnose some of these issues as implementations interpret the standard in different ways.

[lhog]

Probably fixed by @FunMiles

[FunMiles]

Hi guys. I've been very busy with work and then after I had some free time, my linux box didn't want to run Vulkan anymore. Today I got everything back and everything works on linux as well. I did hit a little issue for which I thought I had submitted a PR. I guess I must have inflated my similar PR to imgui to think I also did it for Vookoo. The Validation layer is no more Lunarg but Khronos. If nobody else has an issue with that, I'll submit a PR. MoltenVK has dropped the Lunarg validation layer, so the code won't run on MacOS.

[lhog]

Thanks for the confirmation! And sure, go ahead with your PRs.

[FunMiles]

PR submitted.