Winit 0.30

[paul2t]

Fixes #532

I actually attempted this migration 6 months ago, but failed because of a resize issue on wasm : 07a531e965c0de640730ff043e16d667a3f498b6 Then I tried again a month ago and was able to do it but it required a lot of changes in the API, and using a lot of JS to callback and redraw. It wasn't practical. Today, I am glad to say I fixed it completely: 7e329dfc737e437edfd76199a489add7c2da6f1e I also had to add a check of the size change in the render loop for some reason: 088d5d77af310d6a268d4793b9078996034516dd I'm not sure why, but without it, the rendering is not on the entire canvas surface, there is often a 1 or 2 pixels margin.

Now you can resize the window on the web. The canvas size can be driven by css. Note that max-width and max-height are required. Otherwise the size will be overwritten by winit. I changed the index.html to make the canvas 50% of the size of the window for the wasm examples.

I tested a few examples on native and wasm. I noticed that change partially breaks the multiwindow native example. Now, when you are focused on a window, the other window freezes. I didn't take the time to investigate this issue. But I guess this is a minor issue. Which can be fixed later.

I also updated to egui 0.31 : de00c99dcba8908d5057fd55a04991cdbcbf3151

[paul2t]

Thanks. I've replied to some of the comments. The other comments, I don't remember, I'll check again the reason for those changes.

• We can remove multi window example if it's too much work to fix, it's not a core part of what three-d should support.

I'll take a look at how much work would be needed.

• There's a very different behaviour on web. We can change, but it would be nice to have at least somewhat the same behaviour.

I think it's the same behavior. If you specify max_size, you get a window with this maximum size. If you don't, you get a window taking the whole available space, which can be specified via css. I think this last part is very important if you want to embed the three-d viewer in a web page. If you leave css unspecified, the viewer will take the entire window space.

• Winit window example is not compiling on web.

Thanks. I'll take a look at it.

[asny]

Thanks. I've replied to some of the comments. The other comments, I don't remember, I'll check again the reason for those changes.

Perfect 👌

• We can remove multi window example if it's too much work to fix, it's not a core part of what three-d should support.

I'll take a look at how much work would be needed.

Sounds like a good plan 👍

• There's a very different behaviour on web. We can change, but it would be nice to have at least somewhat the same behaviour.

I think it's the same behavior. If you specify max_size, you get a window with this maximum size. If you don't, you get a window taking the whole available space, which can be specified via css. I think this last part is very important if you want to embed the three-d viewer in a web page. If you leave css unspecified, the viewer will take the entire window space.

With the same index.html file, there's still some differences between this branch (first screenshot) and master (second screenshot).

First, it seems like there's an issue with device pixel ratio/scale factor. three-d assumes viewports in physical pixels. Probably you have a screen with DPR=1, then it's really hard to test.

Second, there's a border around the canvas, where did that come from? 🤔

[joshburkart]

Thank you for doing this @paul2t! Looking forward to the changes landing in main.

[prybicki]

@paul2t, @asny

Hi there, do you plan to make it into main? Winit 0.30 api looks much more convenient and I'd love to have it in three-d before writing a large amounts of event-handling code :smile:

What is the remaining work here? I'm beginner in Rust, but I may look into it with some guidance.

[luxreduxdelux]

Hi, I just tested this and I always seem to be getting a SurfaceCreationError using this branch whereas I do not get any kind of error using the main, normal branch from asny. Will be glad to offer any kind of technical info if you would like to look into it.

[michael-p]

@asny @paul2t Thank you very much for your efforts and hard work on this! It'd be really great to get this merged, as winit 0.28 depends on the unmaintained instant crate, causing tools like cargo-deny to fail CI because of the RUSTSEC advisory. If this migration is too much work in one go maybe update to winit 0.29 first (does not depend on instant anymore)?

[hug-dev]

Hello :wave: ! Since I am also interested into this, I had a quick look at the branch and tried to understand what was remaining to do. In order to move to 0.30 and to remove the deprecation notice mentioned above, a big change will be needed in the flow of how programs using winit are written. It's not very intuitive in the doc but one can't anymore create a Window from an event loop. As described in the Event Handling section of the doc, one needs to create a structure implementing the ApplicationHandler trait which contains two required methods:

• resumed: as far as I understood this is where the window will be created and all the initialization steps requiring a WindowedContext.
• window_event: the main event loop where everything is drawn and the camera moved

Based on what @paul2t has done so far, I could try to see how the examples would look like with the flow above.

I guess the other option would be to ignore the deprecation notice for now and continue with the current approach until the functions are removed.