Closed maltekliemann closed 3 years ago
The tutorial is now changed accordingly. I've tried to keep the explanation of the problem as short as possible. I don't know if there is a more elegant solution for this problem. glfwGetFramebufferSize
is now shoved in a bit awkwardly, instead of being introduced naturally during Swap chain recreation.
When I write "GLFW uses two units when measuring sizes: pixels and screen coordinates [...]", that's a bit of a lie. There are other measurements, but these are the two that count.
Could you elaborate on the changes besides glfwGetFramebufferSize?
My bad, I was careless when I pushed that. Sorry! :(
I've amended the commit. Now it should only contain changes relevant to swapchain extent.
Apologies for not getting back to this sooner, thanks for the work! :+1:
Not to worry! Thanks for the tutorial! :)
When using an HDPI display, using the window size
{WIDTH, HEIGHT}
to determine swapchain image size is incorrect. See the following links:Short version: The window size in GLFW is specified in screen coordinates, but Vulkan requires the swapchain image extent to be specified in pixel. On HDPI displays, these are not the same thing.
Instead, the framebuffer size is now used to determine the swapchain extent. Using the implementation of
chooseSwapExtent
from16_swap_chain_recreation.cpp
seemed appropriate. Beyond "Swap chain recreation" no changes are necessary.I'm a little bit suprised that this hasn't been an issue for anyone. I'm using macOS, and my app doesn't enter the
else
branch, so I don't experience any problems either (Vulkan automatically suggests doubled width and height). The specification doesn't seem to say whenwidth == UINT32_MAX
occurs.