I've been re-evaluating our swapchain API, trying to make it match Vulkan better. After toying with multiple ideas, the most promising one appears to be - to switch the API of our framebuffers according to VK_KHR_imageless_framebuffer. It seems to be widely supported on fresh Vulkan drivers, so we'd be able to map it exactly 1:1 with Vulkan.
Pros: it works great for our new swapchain model, since we no longer need to cache anything internally, when the actual Vulkan adapter supports this. Users would enjoy it quite a bit, since there would be no requirement to constantly create and destroy framebuffers every frame.
Wierds: Vulkan backend to have 2 code paths: caching and non-caching. This is only marginally worse than what we have today. I think the lifetimes are cleaner though: the cache is owned by the API framebuffer object and dies with it.
Cons: OpenGL backend would still need to be changed in non-trivial way, similar to #3552
I've been re-evaluating our swapchain API, trying to make it match Vulkan better. After toying with multiple ideas, the most promising one appears to be - to switch the API of our framebuffers according to
VK_KHR_imageless_framebuffer. It seems to be widely supported on fresh Vulkan drivers, so we'd be able to map it exactly 1:1 with Vulkan.Pros: it works great for our new swapchain model, since we no longer need to cache anything internally, when the actual Vulkan adapter supports this. Users would enjoy it quite a bit, since there would be no requirement to constantly create and destroy framebuffers every frame.
Wierds: Vulkan backend to have 2 code paths: caching and non-caching. This is only marginally worse than what we have today. I think the lifetimes are cleaner though: the cache is owned by the API framebuffer object and dies with it.
Cons: OpenGL backend would still need to be changed in non-trivial way, similar to #3552