Panic on Windows 11 when minimizing a window

[v-po]

I first encountered this when playing around with the example app in Xilem, and then I saw that the glazier examples exhibit the same behavior. I decided to open the issue here because it seems to caused by the RenderContext.resize_surface method. But maybe this is the desired behavior.

wgpu is complaining that a Surface's width and height must be non-zero, and when a window is minimized (on Windows 11 at least), what seems to be happening is that the surface_size calculation from the glazier examples is returning (0, 0).

To me, it's not clear what should be the correct behavior here. Whether or not the callers should check the surface's (or window handle's) size before calling resize_surface. Although, in this example they are checking the width & height before calling surface.configure.

From my testing, the crash is only happening on Windows 11, but it's also the only version of Windows I've tried. macOS doesn't seem to have this problem.

Stacktrace

```bash thread 'main' panicked at 'Error in Surface::configure: Validation Error Caused by: Both `Surface` width and height must be non-zero. Wait to recreate the `Surface` until the window has non-zero area. ', C:\Users\dvh\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.1\src\backend\direct.rs:771:18 stack backtrace: 0: std::panicking::begin_panic_handler at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library\std\src\panicking.rs:593 1: core::panicking::panic_fmt at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library\core\src\panicking.rs:67 2: wgpu::backend::direct::Context::handle_error_fatal > at C:\Users\dvh\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.1\src\backend\direct.rs:345 3: wgpu::backend::direct::impl$7::surface_configure at C:\Users\dvh\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.1\src\backend\direct.rs:771 4: wgpu::context::impl$5::surface_configure at C:\Users\dvh\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.1\src\context.rs:2174 5: wgpu::Surface::configure at C:\Users\dvh\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.17.1\src\lib.rs:4601 6: vello::util::RenderContext::resize_surface at C:\Users\dvh\.cargo\git\checkouts\vello-597be072a8b1ddcb\9d7c4f0\src\util.rs:98 7: shello::WindowState::render at .\examples\shello.rs:96 8: shello::impl$1::paint at .\examples\shello.rs:129 9: glazier::backend::windows::window::WndState::render at .\src\backend\windows\window.rs:414 10: glazier::backend::windows::window::impl$8::window_proc::closure$2 at .\src\backend\windows\window.rs:763 11: enum2$ > >::map,tuple$<>,glazier::backend::windows::window::impl$8::window_proc::closure_env$2> at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3\library\core\src\option.rs:1075 12: glazier::backend::windows::window::MyWndProc::with_wnd_state > at .\src\backend\windows\window.rs:453 13: glazier::backend::windows::window::impl$8::window_proc at .\src\backend\windows\window.rs:747 14: glazier::backend::windows::window::win_proc_dispatch at .\src\backend\windows\window.rs:1526 15: DispatchMessageW 16: CallWindowProcW 17: wglSwapBuffers 18: DispatchMessageW 19: DispatchMessageW 20: GetClassLongW 21: KiUserCallbackDispatcher 22: NtUserDispatchMessage 23: DispatchMessageW 24: glazier::backend::windows::application::Application::run at .\src\backend\windows\application.rs:172 25: glazier::application::Application::run at .\src\application.rs:145 26: shello::main at .\examples\shello.rs:39 27: core::ops::function::FnOnce::call_once > at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3\library\core\src\ops\function.rs:250 ```

[DJMcNab]

Thanks for the report!

This is a known issue - we've discussed it a couple of times on Zulip: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/vello.200.2E0.2E1/near/322106970

And: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Zero.20area.20surface.20error.20from.20wgpu

I'm not entirely certain what the best way to fix this is - as mentioned in the first link, the naïve solution of deleting the swapchain feels suboptimal in cases where (e.g.) the alt-tab menu is opened, as I would hope that animations would continue during that, even for minimised windows.

But a contribution to implement the solution of special-casing a resize event where any axis is zero sized to delete the surface would be welcome!