vulkano-rs / vulkano

Safe and rich Rust wrapper around the Vulkan API
Apache License 2.0
4.48k stars 433 forks source link

Make image_index and final_views accessible, and add new example. #2473

Closed coolcatcoder closed 6 months ago

coolcatcoder commented 6 months ago

Being able to access image_index and final_views in VulkanoWindowRenderer should make creating frame buffers easier. The new example should make it easier to learn vulkano-util.

I'm still quite new to rust and vulkan, as such I have not yet figured out how to make multi-window-game-of-life and interactive-fractal use these changes to store their frame buffers, instead of creating one every frame.

This is my attempt at a solution to this issue.

Changelog:

### Breaking changes
- VulkanoWindowRenderer.acquire() now takes in an FnMut(&Vec<Arc<ImageView>>).
  This means that a closure can be called when the swapchain gets recreated.
  It now passes out a Result<(Box<dyn GpuFuture>, u32), VulkanError>.
  That u32 is the image_index so that you can index into your array of frame buffers.

### Additions
- VulkanoWindowsRenderer.final_views() allows access to the swapchain images.

This is the first time I've created a proper pull request, so I hope I did it correctly.

hakolao commented 6 months ago

There are already methods:

    pub fn swapchain_image_view(&self) -> Arc<ImageView> {
        self.final_views[self.image_index as usize].clone()
    }

    pub fn image_index(&self) -> u32 {
        self.image_index
    }

Do these help?

coolcatcoder commented 6 months ago

Unfortunately for swapchain_image_view(), it returns the current swapchain image. Useful for creating a framebuffer every frame, but not useful for creating framebuffers in advance. As for image_index(), I just somehow completely missed that. That is definitely better than my solution of returning the u32 as part of acquire(), whoops.

coolcatcoder commented 6 months ago

The reason I decided to name the callback function on_recreate_swapchain, instead of mentioning resize, is because the swapchain could be recreated for more reasons than just a resize, so this name feels more accurate.

(Also just realised I messed up the last commit's name… It should not have that "to on_recreate_swapchain" on the end, whoops.)