perf(window): hoist invariant per-frame Vulkan info structs to members #78

Merged

catbot merged 1 commit from claude/issue-43 into master

2026-06-16 17:27:49 +02:00

catbot commented

2026-06-16 17:27:38 +02:00

Member

Summary

Window::Render() reconstructed cmdBufInfo, the VkImageSubresourceRange, both VkImageMemoryBarrier structs, and VkPresentInfoKHR on the stack every frame, although only the barriers' image (and the acquire barrier's oldLayout) ever vary between frames.

This hoists those invariants to members initialised once in the constructor. Each frame now patches only acquireBarrier.image/oldLayout and presentBarrier.image.

presentInfo.pImageIndices/pSwapchains point at the currentBuffer/swapChain members, so they track value changes (including swapchain recreation) automatically.
The per-frame renderComplete != VK_NULL_HANDLE check was dead (the semaphore is created once at construction and never cleared), so it is removed; the wait semaphore is wired into presentInfo in the constructor.

VkSubmitInfo was already a member initialised once, so it was left as-is.

Testing

crafter-build test — 3 passed (MouseScroll, BLASBuildOptions, PushConstantRewrite).
Ran HelloWindow and HelloUI against the headless compositor with full Vulkan validation layers enabled: no layout/barrier (VUID) errors across the acquire → barrier → multi-pass → present → barrier loop. Screenshot below confirms correct rendering.

Screenshots

Resolves #43

## Summary `Window::Render()` reconstructed `cmdBufInfo`, the `VkImageSubresourceRange`, both `VkImageMemoryBarrier` structs, and `VkPresentInfoKHR` on the stack every frame, although only the barriers' `image` (and the acquire barrier's `oldLayout`) ever vary between frames. This hoists those invariants to members initialised once in the constructor. Each frame now patches only `acquireBarrier.image`/`oldLayout` and `presentBarrier.image`. - `presentInfo.pImageIndices`/`pSwapchains` point at the `currentBuffer`/`swapChain` members, so they track value changes (including swapchain recreation) automatically. - The per-frame `renderComplete != VK_NULL_HANDLE` check was dead (the semaphore is created once at construction and never cleared), so it is removed; the wait semaphore is wired into `presentInfo` in the constructor. `VkSubmitInfo` was already a member initialised once, so it was left as-is. ## Testing - `crafter-build test` — 3 passed (MouseScroll, BLASBuildOptions, PushConstantRewrite). - Ran `HelloWindow` and `HelloUI` against the headless compositor with full Vulkan validation layers enabled: no layout/barrier (VUID) errors across the acquire → barrier → multi-pass → present → barrier loop. Screenshot below confirms correct rendering. ## Screenshots ![result](https://forgejo.catcrafts.net/attachments/ddb673a9-db09-4955-8bbd-7b3de5ca06bf) Resolves #43

result.png

11 KiB

catbot added 1 commit

2026-06-16 17:27:38 +02:00

perf(window): hoist invariant per-frame Vulkan info structs to members (#43 ) 38616d81ef

Window::Render() rebuilt cmdBufInfo, the subresource range, both
VkImageMemoryBarrier structs, and presentInfo on the stack every frame
even though only the barriers' image (and the acquire barrier's
oldLayout) ever change. Hoist them to members initialised once in the
constructor; Render() now patches only the two varying fields.

presentInfo.pImageIndices/pSwapchains point at the currentBuffer and
swapChain members, so they track value changes (including swapchain
recreation) automatically. The render-complete wait semaphore is fixed
for the window's lifetime, so the per-frame `renderComplete != NULL`
check — set once, never cleared — was dead and is removed; the
semaphore is wired into presentInfo in the constructor instead.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

catbot merged commit fa35d86021 into master

2026-06-16 17:27:49 +02:00

catbot deleted branch claude/issue-43

2026-06-16 17:27:49 +02:00

catbot referenced this pull request from a commit

2026-06-16 17:27:50 +02:00

Merge pull request 'perf(window): hoist invariant per-frame Vulkan info structs to members' (#78) from claude/issue-43 into master