I see. How do I get rid of the vulkan error?
If you are getting a Vulkan error while using wgpu, then that is (in principle) a bug in wgpu, which is supposed to validate all inputs before they get to Vulkan. I've heard that rendering while resizing is tricky and hard to do flawlessly, but you shouldn't have to deal with any errors, just wait for things to settle out a frame later, if things are working properly.
I can't advise you any further on troubleshooting or workarounds because I don't work with Vulkan.
You don't have to know vulkan to understand the error, but basically it needs the scale_factor as indicated by the error. Where? idk.
From memory, I've found for rendering while resizing is pretty much what you've got: store what the next frame size should be, and (what I'm guessing the other side is) resizing all your view buffers if it's changed since the last frame.
This seems to work even if you're rendering off the main/UI/input thread... so long as you're careful about your locking/buffering the size update so it definitely arrives before the next request for an image from the swap chain. I guess it waits for that to "actually" resize the window?
Maybe there's more trouble across platforms, I've only used this in Vulkan and DX12 on Windows, where it seems the same.
wdym by "store what the next frame size should be?"
I'm not sure what part confused you: I meant literally just storing the size you're going to resize the render to somewhere, such as a resize_to: Option<Size> of some sort.
In wgpu terms, I believe the minimum is that after a resize you must call Surface::configure with the size you just got from the resize event after you have finished presenting the last frame and released the SurfaceTexture using the old size, and before you get the next SurfaceTexture with Surface::get_current_texture, though you'll also need to update the depth buffer, viewport, projection matrix and maybe things like post effect buffers that match the surface size for things to look right.
Is this really the intended way to use wgpu with winit? Just kinda in-place force all of the async calls to be sync?
Yes, unless you want to integrate with an async runtime. IMHO, you would need a very compelling reason to do so (e.g., you have no choice because you are targeting a web browser). Most applications will not care about blocking the thread for the few cases where wgpu gives you an async fn.
2 Likes
Beforehand you could make the window and all the dependent async resources in your own async function, using pollster (or any other runtime) only once at the top level, as all the current wgpu examples do.
Since wgpu-core (which is what's used when not using WebGPU in the browser) has a synchronous API, in theory you shouldn't even need a runtime at all, just manually polling the future with a dummy context should immediately return Ready. But pollster is absolutely tiny and easier to use than that, so why not?
2 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.