Acquire the swapchain in endFrame, not beginFrame - #5
Merged
Conversation
beginFrame acquired the swapchain texture at the top of the frame, so the drawable was held across all of the caller's per-frame CPU work before the presenting blit finally submitted it. On Metal that starves CAMetalLayer's drawable pool: [layer nextDrawable] returns nil under contention, SDL does not check it, and the frame is silently never presented. Nothing needs the swapchain until the blit, so acquire it there. Size the present framebuffer from SDL_GetWindowSizeInPixels rather than the swapchain dimensions, so a transient acquire hiccup can no longer tear down and rebuild every attachment (which also reset double-buffered attachment parity). The two agree by construction; the blit now scales if they ever disagree mid-resize. When no drawable is available the command buffer is still submitted, so the frame's GPU work completes and only presentation is skipped. Also treat a NULL texture from either acquire wrapper as unavailable. SDL documents returning success with a NULL handle when the window is minimised or too many frames are in flight, and that handle must not be passed back into SDL; both backends do exactly this on the non-blocking path. Refs jdolan/quetoo#945
Copilot stopped reviewing on behalf of jdolan due to an error
August 17, 2026 15:07
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
beginFrame acquired the swapchain texture at the top of the frame, so the drawable was held across all of the caller's per-frame CPU work before the presenting blit finally submitted it. On Metal that starves CAMetalLayer's drawable pool: [layer nextDrawable] returns nil under contention, SDL does not check it, and the frame is silently never presented. Nothing needs the swapchain until the blit, so acquire it there.
Size the present framebuffer from SDL_GetWindowSizeInPixels rather than the swapchain dimensions, so a transient acquire hiccup can no longer tear down and rebuild every attachment (which also reset double-buffered attachment parity). The two agree by construction; the blit now scales if they ever disagree mid-resize. When no drawable is available the command buffer is still submitted, so the frame's GPU work completes and only presentation is skipped.
Also treat a NULL texture from either acquire wrapper as unavailable. SDL documents returning success with a NULL handle when the window is minimised or too many frames are in flight, and that handle must not be passed back into SDL; both backends do exactly this on the non-blocking path.
Refs jdolan/quetoo#945