Fixed crash under Wayland when using a scaling factor.

[Sebastian-Dawid]

When running the example on a Wayland system using a scaling factor of 3, the example crashes since the size of the initial buffer created by GLFW is not divisible by the scaling factor. This violates the Wayland protocol, which results in a crash when trying to present to the wl_surface:

wl_surface#24: error 2: Buffer size (554x646) is not divisible by scale (3)

Allowing for a resize of the swapchain images before presenting fixes this issue.

I am admittedly not entirely sure why this fixes the issue, since when logging the resizes, there is at least one resize to a buffer size that is invalid, without causing a crash:

info: framebuffer size : swapchain extent before resize
info: 554, 646 : 800, 600
info: 1662, 1938 : 554, 646

But I assume that this is related to when GLFW calls wl_surface::set_buffer_scale to set the scale of the created surface and wl_surface::commit to apply this change. See the Wayland spec for wl_surface.

[Snektron]

Thanks! Does this reordered resizing loop work on other platforms as well? What if you set the initial size to .suboptimal for force a recreation of the swapchain, or does it need a present in order to pick up on proper size?

Also, shouldn't this be a GLFW issue rather than an application issue? I'm fine with accepting the fix, but it seems the wrong location to fix it...

[Sebastian-Dawid]

Thanks! Does this reordered resizing loop work on other platforms as well?

I tested it on X11 and Wayland, and at least on Plasma (X11 and Wayland), Sway (Wayland) and i3 (X11) it didn't cause any problems. I don't have access to a Windows or MacOS machine so I can't test if it changes anything on those platforms.

What if you set the initial size to .suboptimal for force a recreation of the swapchain, or does it need a present in order to pick up on proper size?

We could set the initial value to .suboptimal, but I am not really sure how the swapchain would be suboptimal before presenting. The window also can't really be resized before presenting at least once since we poll the window events at the end of the main loop. (Unless then window is created minimized, but then we need to resize anyway.)

Also, shouldn't this be a GLFW issue rather than an application issue? I'm fine with accepting the fix, but it seems the wrong location to fix it...

I am not really sure how this could be fixed in GLFW, since the issue is caused by not resizing before presenting, which may cause us to present a swapchain image of a size that is no longer valid. GLFW resizes the window correctly, but it presumably does this at the glfwPollEvents call and we don't resize between that call and trying to present.