We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

I assume this is X11 and not Wayland, right? For X11, SDL_Vulkan_GetDrawableSize() is literally just SDL_GetWindowSize().

I would say clamping to the min/maxImageExtent is the correct approach and not a workaround, unless you never get a resize event that puts you at the correct dimensions when dragging completes.

Something worth trying: use an SDL event filter to catch resize events as X11 sends them. Otherwise they're going into a separate queue and when you get the event from SDL from SDL_PollEvents, it's possible the X server has moved on and resized the window further and you don't have that information yet.

Also worth trying, first: make note of resizes, but don't actually create a swapchain until the event queue is empty (SDL_PollEvent() returns 0). This is a better idea in any case: if a big pile of resize events have queued up, you only want to do this once per frame.

These are just ideas, though. Let me know what you find.

--ryan.

(In reply to Ryan C. Gordon from comment #1)
> I assume this is X11 and not Wayland, right? For X11,
> SDL_Vulkan_GetDrawableSize() is literally just SDL_GetWindowSize().
> 
> I would say clamping to the min/maxImageExtent is the correct approach and
> not a workaround, unless you never get a resize event that puts you at the
> correct dimensions when dragging completes.
> 
> Something worth trying: use an SDL event filter to catch resize events as
> X11 sends them. Otherwise they're going into a separate queue and when you
> get the event from SDL from SDL_PollEvents, it's possible the X server has
> moved on and resized the window further and you don't have that information
> yet.
> 
> Also worth trying, first: make note of resizes, but don't actually create a
> swapchain until the event queue is empty (SDL_PollEvent() returns 0). This
> is a better idea in any case: if a big pile of resize events have queued up,
> you only want to do this once per frame.
> 
> These are just ideas, though. Let me know what you find.
> 
> --ryan.

Yes this is X, not Wayland. I always loop my events until SDL_PollEvent() returns 0, but I suspect there's a race condition where the event queue starts filling up again by the time it recreates the swapchain.

I've tried each possibility. I've recreated the swapchain when vkAcquireNextImageKHR() returns OUT_OF_DATE or SUBOPTIMAL. I've filtered (emptied the entire queue of) events for SDL_WINDOWEVENT_RESIZED and passed the event-given coordinates (data1 and data2) but I suspect a race condition between emptying the queue and recreating the swapchain where the "new" coordinates given by the resize event are already outdated.

I do see that the canonical solution is to simply CLAMP() the given coordinates between min and max image extents, in which case the "bug-fix" would just be adding a note of this in the header comments of SDL_Vulkan_GetDrawableSize().

"This function may return spurious or out-of-date results if the window is in the middle of being resized. The `width` and `height` should be clamped between their respective `minImageExtent` and `maxImageExtent` of their `VkSurfaceCapabilitiesKHR` structure returned by `vkGetPhysicalDeviceSurfaceCapabilitiesKHR()`."

Although I wonder why one should use SDL_Vulkan_GetDrawableSize() over currentExtent in the first place.

(In reply to colaeuphoria from comment #3)
> Although I wonder why one should use SDL_Vulkan_GetDrawableSize() over
> currentExtent in the first place.

I imagine the thinking is to match SDL_GL_GetDrawableSize(), which takes into account DPI scaling, but I'm not super-familiar with this piece of SDL yet.

--ryan.