wgpu and winit update tracker

[ifsheldon]

Hey! Here is just a heads-up that wgpu 0.18 and winit 0.29.2 came up recently with a lot breaking changes.

For the breaking changes from wgpu, please see https://github.com/gfx-rs/wgpu/releases/tag/v0.18.0. I think these are easy to be fixed when upgrading from 0.17.

However, for the newer winit, it brings a LOT API changes. See https://github.com/rust-windowing/winit/releases/tag/v0.29.2

I think virtually a rewrite on sections about windowing is needed.

If it helps, I just did the upgrade to winit 0.29.2 for my wgpu DVR renderer in this commit. In short, we need to:

• enable a feature rwh_05 of winit for raw-window-handle traits
• checkout (a lot) breaking changes about window events and key events
• handle subtle changes to redrawing behavior

But wait, why do we need to upgrade winit?

I don't know honestly, because when I upgraded wgpu from 0.17 to 0.18 while keeping winit as 0.27, my code weirdly breaks because an abnormal resize event which gives a new window size to (u32::max, u32::max). I thought that should be a bug from winit so I upgraded winit as well. Probably winit 0.27 does not work with macOS Sonoma, I don't know, but now the problem is gone, so I don't want to dig deeper.

[sotrh]

I've already upgraded to 0.18, but an upgrade to winit 0.29 might take a little longer. I created different demo using winit 0.29 so hopefully it shouldn't be too painful.

[vfx1b]

Hi, I've been working through the learn-wpgu book, but with updated winit and wgpu. Id be happy the help out with rewriting stuff!

[ifsheldon]

wgpu 0.19 is just released. We just need a few minor changes to remove the last bit of unsafe code in the tutorial when creating a Surface. It works perfectly in my webgpu DVR renderer. But I'm using the latest winit so I don't know how it works with older winit. The breaking changes of wgpu 0.19 are not fully documented but it's easy to fix the breaking pieces. Just for your information, my changes in my renderer due to the wgpu update are here.

[tgross35]

Winit 0.30 was released just yesterday, which seems to prefer the ApplicationHandler trait rather than an event loop. This was very tricky to get working but I think I have something, which I posted to rust-windowing/winit#3626 (comment).

[ifsheldon]

@tgross35 Thanks for the heads-up. How about async methods?

I have the following code in my GfxStates::new()

let instance = wgpu::Instance::default();
        let surface = instance.create_surface(window).expect("Failed to create surface");
        // need adapter to create the device and queue
        let adapter = instance
            .request_adapter(&wgpu::RequestAdapterOptions {
                power_preference: wgpu::PowerPreference::default(),
                force_fallback_adapter: false,
                compatible_surface: Some(&surface),
            })
            .await
            .unwrap();
        let (device, queue) = adapter
            .request_device(
                &wgpu::DeviceDescriptor {
                    label: None,
                    required_features: wgpu::Features::empty(), //The device you have limits the features you can use
                    required_limits: wgpu::Limits::default(), //The limits field describes the limit of certain types of resource we can create
                },
                None,
            )
            .await
            .unwrap();

but the trait method is synchronous, so do we have to introduce a blockon() to get the result?

[ifsheldon]

Just FYI, I updated my code to wgpu 0.20, which was released 5 hrs ago and is very easy to migrate to. Just follow rustc's error messages.

[tgross35]

I have just been using block_on for those two functions, but that is a good point. I wish I better understood why these were async at all, I guess maybe this comes from webgpu? Seems like an unlikely point to have performance wins from a nonblocking API.

(reposting here since I accidentally posted this comment on the winit tracker)

[sotrh]

Yeah the async bit is from the webgpu spec.