winit paradigm has changed, what now?

[shi-yan]

I'm trying to learn this project along with the winit library.

I notice that the programming paradigm has changed for winit, making the examples of this project a bit obsolete.

before, we create the adapter and device, and then we explicitly call the winit event loop.

Now, the official winit example uses a trait to implement event handling.

https://docs.rs/winit/latest/winit/

in the example code seen in the above link, the window is created in a member function resume(). Only when that function is called, I know the size of the window, hence I have to create the surface/Adapter/device in that function.

however, adapter creation is an async function. What should I do here? Add code to wait for the future to finish? or is there a smarter way?

Second, I don't know if I should keep an instance of the Device or I should create one every time I need a Device. According to the WebGPU spec, a Device can be lost at anytime. is it the same for this library?

[SludgePhD]

When targeting desktop, you can just use pollster::block_on to block until the future resolves.

According to rust-windowing/winit#3626 (comment), winit will gain an async shim for handling this correctly when targeting the web in a future release. Until then, the deprecated functionality should still work like it used to.