Hello,
I’m just want to know, whether there are some additional flags which can be set for the various objects which need to be recreate after a surface resize (e.g. additional swapchain create flags).
If not, maybe in the future could there be flags for such needs?
What flags? What objects? What needs?
There is a performance issue? Can you elaborate?
Anyway, IMO the driver has all the information to make it reasonably efficient.
I don’t think there’s much performance needed anyway (recreation is not usually very frequent).
Unfortunality I have some flickering during resizing my window which simple shows a triangle (with interpolated colors).
I could give you my code but I do not think, that the code is really readable in the current state (It’s my vulkan test code e.g. testing resize approaches 
also the code is very big as usual for vulkan code).
Nevertheless you can ask me if you want it.
From what I’ve learned so far according surface resize there are several “objects” which have to be recreate (“object” == vulkan struct).
Those are for example:
- The swapchain itself, it needs a new size
- swapchain imageviews, swapchain images and framebuffers
- The commandbuffers
(- if the dynamic viewport and sciscorstate isn’t enabled the graphics pipeline needs recreation too!)
However I also can use my old swapchain for creating the new one with specifying it in the swapchain create info.
I’m searching for a solution to avoid flickering and this implies, that I’m searching for additional options or approachs for handling a window resize.
1 Like
Ok. Well, that doesn’t sound like a performance issue really. From Vulkan perspective it should be quite seamless (no flicker) — at least on platforms that prefer to return SUBOPTIMAL rather than OUT_OF_DATE (the driver is allowed to keep the presented Image even after swapchain destruction).
AIS, I think the driver has all the information to make it reasonably efficient and as such I would not consider it Vulkan (as in the API specification) problem:
The swapchain itself, it needs a new size
Yeah, it may take a bit. Some talking with the OS and internal synchronization may be needed.
Providing oldSwapchain could help. The driver could be able to reuse its guts, when it gets destroyed.
swapchain imageviews, swapchain images and framebuffers
Could be wrong, but they seem like quite light-weight constructs.
Only the Images need memory allocation. That would be (if done correctly) either one allocation (or even 0 if smaller swapchain and oldSwapchain gets reused as above).
The commandbuffers
It seem to be cheap to the point it is often done each frame.
Nevertheless it could be smart enough to reuse resources. Especially if you re-record the same command buffer with the new (almost same) content.
graphics pipeline needs recreation too!
It could use the Pipeline Cache to speed things up.
I’m searching for a solution to avoid flickering and this implies, that I’m searching for additional options or approachs for handling a window resize.
Might as well be immature drivers. Or the OS/Window manager doing something nefarious.
For completeness, what platform (OS, GPU, driver) are you on?
1 Like
[QUOTE=krOoze;41261]Ok. Well, that doesn’t sound like a performance issue really. From Vulkan perspective it should be quite seamless (no flicker) — at least on platforms that prefer to return SUBOPTIMAL rather than OUT_OF_DATE (the driver is allowed to keep the presented Image even after swapchain destruction).
AIS, I think the driver has all the information to make it reasonably efficient and as such I would not consider it Vulkan (as in the API specification) problem:
Yeah, it may take a bit. Some talking with the OS and internal synchronization may be needed.
Providing oldSwapchain could help. The driver could be able to reuse its guts, when it gets destroyed.
Could be wrong, but they seem like quite light-weight constructs.
Only the Images need memory allocation. That would be (if done correctly) either one allocation (or even 0 if smaller swapchain and oldSwapchain gets reused as above).
It seem to be cheap to the point it is often done each frame.
Nevertheless it could be smart enough to reuse resources. Especially if you re-record the same command buffer with the new (almost same) content.
It could use the Pipeline Cache to speed things up.
Might as well be immature drivers. Or the OS/Window manager doing something nefarious.
For completeness, what platform (OS, GPU, driver) are you on?[/QUOTE]
Before I start, thanks for helping me and of course thanks for this information 
Seems like I’ve understanded quite a lot right so far. If you could give me a site which contains additional information about the various os specific window handlers this would be great!
I’m using Microsoft Windows 10 with a Nvidia GTX 940M and with the default Vulkan driver by Nvidia.
The flickering occurs definitely more often if I make the window bigger. There is less flickering during downsizing.
IDK but Vulkan has not ever shown me that my Swap chain is out of date or else not usable anymore(I do know those result values and would have used them if they had occurred 
). I recreate only my swap chain because after resizing the window is blank…
Before I start, thanks for helping me and of course thanks for this information
Well, full disclosure: I am not Khronos, do not make drivers and my Vulkan XP is not that great.
I don’t think such information is (as usual) readily available. Some guesses have to be made.
default Vulkan driver by Nvidia
What’s a “default” driver? Use the newest (from NVIDIA site).
You helped me overcome my laziness and try to properly implement this in my humble hobby projects. 
The flickering occurs definitely more often if I make the window bigger.
If I use no background brush the new space created while resizing collects garbage (becomes some mess of black and white patterns) until it gets painted. Is it something like that?
IDK but Vulkan has not ever shown me that my Swap chain is out of date or else not usable anymore
Oh yeah, I don’t get VK_SUBOPTIMAL_KHR either. Spec seems to be a bit ambiguous about it to me. Guess I will ping those poor people another Issue :twisted:.
I’ll answer tomorrow , here it’s too late.
PS:
Default driver means always the latest 
PS:
On my AMD other than the effect described above (which I suspect is still fixable using win32 API), I do not have any flickering during resize.
You may try my example of this yourself: https://github.com/krOoze/Hello_Triangle
Nvidia fixed graphic issues :lol: ! Now my geometry shader is working correct but I still encounter some flickering during resize :mad:!