window glitch when resizing

[visual flame]

i followed https://vulkan-tutorial.com till swapchain recreation. when i try to resize, the window will not re-render in real time, it resizes the triangle and re-render the window only AFTER i release my mouse click. how can i change this?

[rose remnant]

ohh that's different then

that's just windows

[weak reef]

Yeah I'm pretty sure that is expected unfortunately

[visual flame]

it is glfw issue aint it?

[wraith magnet]

the windows event loop blocks during resize and you would have to present in the WM_SIZE callback (or WM_NCCALCSIZE, or any of the other events called in the resizing process)

basically switching to a synchronized render callback during resizing

If you're using glfw, the simplest way is to hook into glfwSetFramebufferSizeCallback

[visual flame]

smth like tiz?

[wraith magnet]

you could have to complete your frame render and present in that callback

After the WM_NCCALCSIZE event has been processed, you have a limited time to present before windows will do its own thing to your window during resize (causing annoying resizing artifacts)

[visual flame]

so... i put those functions in that framebufferResizeCallback()?

[wraith magnet]

Yea, or defer out to a draw function that synchronously completes the frame render and blocks until present

As long as you're presenting before you leave that callback, you should be ok

[fresh vine]

You don't need to mess around with size/calcsize messages if doing raw Win32. Just handle wm_paint correctly.

Set hredraw/vredraw on your class. Handled wm_paint by calling your render() function (in addition to calling it from your main event loop), then call validateRect()

Or purely rendering and event pumping on separate threads. (Or just use glfw 😉 )

[wraith magnet]

Continuing asynchronous rendering during resizing itself causes fun issues if you don't block the actual sizing processing events themselves (or wm_paint would also work fine there)