Vulkan on Android 3 — Render Nothing with Lots of Hidden Details Part 3

Jin-Long Wu
3 min readOct 4, 2018

--

Photo by R Mo on Unsplash

Today we are going to discuss swapchains, raw destinations of rendering result.

Swapchain

A swapchain object (a.k.a. swapchain) provides the ability to present rendering results to a surface and is an abstraction for an array of presentable images(VkImage) that are associated with a surface. A native window is only associated with one non-retired swapchain at most and at a time. Further, swapchains can only be created for native windows that have a Vulkan graphics API surface(VkSurface) associated with them. Programmatically it is represented by a VkSwapchainKHR handle. So, a VkSurface is the basis of a swapchain creation. Also, a VkDevice is needed as well.

Let’s inspect Swapchain class and first, the constructor does not create the member _swapchain. The reason is _swapchain gets invalid when screen orientation change and I don’t want to recreate the object but the member inside so I extract the job of the constructor to CreateSwapchain. Maybe I will find this idea sucks someday, but now let’s just leave it alone.

_graphics and _present are used for VkSwapchain creation specifying what kinds of operations can access swapchain images. _extent2D and _surfaceFormat are the size and the color format of swapchain. Finally, _images are the images contained in swapchain and _imageViews are derived from _images, respectively.

Before creating a swapchain, some prerequisites like the size and the color format of a swapchain, and how images of a swapchain are presented, must be queried. ChooseSwapchainPresentMode is worth a look. VK_PRESENT_MODE_MAILBOX_KHR can be used to implement triple buffering and is our best choice for minimal latency. It is better to request at least three swapchain images to be created to provide non-blocking guarantees for vkAcquireNextImageKHR(we’ll come back to the function in the future). VK_PRESENT_MODE_FIFO_KHR is guaranteed to be available by Vulkan and is stick to monitor refresh rate. It behaves in the same way as so-called vertical synchronization of monitors. VK_PRESENT_MODE_FIFO_RELAXED_KHR is similar to VK_PRESENT_MODE_FIFO_KHR except that when if a vertical blanking period has already passed since the last update of the current image, and if the rendering waited completes before another vertical blanking period, the presentation engine does not wait for the next vertical blanking, and instead, it ‘ll present the completed image immediately. However, it means this mode may result in visible tearing in this case.

Now we are prepared to start constructing a VkSwapchain. CreateSwapchain call functions we explained before to get most of the data needed and assign them to fields of VkSwapchainCreateInfoKHR.

getScreenExtent is a C++ function variable assigned from external to get screen resolution.

imageSharingMode specifies that access to any range or image subresource of the object will be exclusive to a single queue family at a time or multiple queue families will access to any range or image subresource of the object concurrently. If indices of graphics and present queue families are not identical, we must specify individual indices of both queue families and imageSharingMode must be assigned to VK_SHARING_MODE_CONCURRENT.

VkImages contained in a VkSwapchain are not directly accessible so VkImageViews are used instead. CreateImageViews creates the same amount of image views as the images contained in the swapchain. Note image format should be the same to that of the swapchain and we are to create VK_IMAGE_VIEW_TYPE_2D image view for being a normal 2D image.

--

--