How to handle window resizing on macOS

[DagAgren]

I am playing around with using wgpu in a macOS project (and eventually iOS, but haven't tried it yet).

Right now I am struggling with how to handle window resizing. I'm currently rendering using CVDisplayLink, and for each frame checking if the size of the window has changed since last frame, and if so, I create a new swap chain.

This is causing double buffer flickering when resizing the window - every other frame is a frozen frame from the double buffer, and ever other is live updating and correct.

If I do not recreate the swap chain at all, it actually looks slightly better: Rendering seems to block completely for short times while resizing, and the contents of the previous frame is just resized instead.

Any clues what is going on? Am I doing something wrong, or is wgpu?

(Also, if I fullscreen, my framerate drops through the floor, and I get occasional squares of corruption on individual frames, but is that the same issue as #78 ?)

[kvark]

Did you try running https://github.com/gfx-rs/wgpu-rs examples and see how they resize in your environment?

[DagAgren]

No, I will try that.

[DagAgren]

Sorry, I am not very familiar with rust, so, how do I actually build the examples? "cargo build" does not seem to do it?

[kvark]

@DagAgren no worries, we'd be happy to walk you through. Sorry about inconvenience!
Basically, if you install Rust+Cargo (e.g. via https://rustup.rs/), you can do:

git clone https://github.com/gfx-rs/wgpu-rs
cd wgpu-rs
cargo run --example cube --features metal

[DagAgren]

Thanks!

Resizing is very broken in a different way in the examples: The animation freezes, and the last frame is stretched to the window size.

[DagAgren]

The examples also have the same problem where going to fullscreen will kill the framerate. The animation to fullscreen is of course also frozen the same way.

[kvark]

Thank you for verifying! One of the things we are currently doing is stalling the CPU to wait for GPU on resizing:

wgpu/wgpu-native/src/device.rs

Line 1843 in 32399cf

device.raw.wait_idle().unwrap();

There is also a number of issues with have with swapchain in gfx-rs Metal backend, including that fullscreen bug. We are looking for ways to resolve them, e.g. gfx-rs/gfx#2882

[DagAgren]

All right! I guess in conclusion I should not try too hard to resolve this on my side, but rather wait a while for a few more issues to be addressed and then try again?

[kvark]

Yes, that's the way

…

On Jul 19, 2019, at 04:40, Dag Ågren ***@***.***> wrote: All right! I guess in conclusion I should not try too hard to resolve this on my side, but rather wait a while for a few more issues to be addressed and then try again? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mtak-]

@DagAgren I would also caution that displaylink runs on a background thread. This could be the cause of the corrupted frames. If you are using objc/swift for CVDisplayLink, I would suggest switching to the display-link crate. It adds a send requirement on the callback which should make any threading issues more obvious.

Also, IIRC winit doesn't support live resize on macos super well until winit 0.20 comes out.

[seivan]

@mtak- It happens without using DisplayLink on macOS as well. Then again Metal might use one internally.

[kvark]

I consider this fixed by #330. Please re-open otherwise!