Winit 0.29 follow up

[ThierryBerger]

A few shortcuts were taken in #10702 in order to merge it in a reasonable amount of time.

This issue serves to :

• coordinate addressing those follow-ups
• offer a place to discuss the winit update
• mentoring opportunities

Feel free to create or ask a dedicated issue for any listed task, if you feel like it's worth it.

Known regressions (important follow ups?)

• ⚠️ Fix big problem in event loop Winit 0.29 follow up #11052 (comment)
  • Preformance fix in Fix perf degradation on web builds #11227
  • more eventloop cleanups : https://github.com/bevyengine/bevy/pull/11227/files?diff=unified&w=1#diff-b1447f30819280931099e7498b2ced388a98de5cda1b631b493107bb96193cc0R806
• ⚠️ UpdateMode::Reactive is broken
  • Button example is broken #11235
  • WinitSettings::desktop_app() is broken #11320
    • Fixed in Fix Reactive and ReactiveLowPower update modes #11325
• Provide an API for reacting when a specific key from current layout was released.
  • possible solutions: use winit::Key from winit::KeyEvent ; mapping between KeyCode and Key ; or retrieve exact layout.
• We don't receive characters through alt+numpad (e.g. alt + 151 = "ù") anymore ; reproduced on winit example "ime". maybe related to Pressing Alt on Windows discards key information rust-windowing/winit#2945
• (windows) Window content doesn't refresh at all when resizing. By reading EventLoop 3.0 Changes rust-windowing/winit#2900 ; I suspect we should just fire a window.request_redraw(); from AboutToWait, and handle actual redrawing within RedrawRequested. I'm not sure how to move all that code so I'd appreciate it to be a follow up.
• (windows) unreleased winit fix for using set_control_flow in AboutToWait Windows: set_control_flow has no effect from AboutToWait event rust-windowing/winit#3215
  • Fixed in winit 0.29.4

Follow up

I'd like to avoid bloating this PR, here are a few follow up tasks worthy of a separate PR, or new issue to track them once this PR is closed, as they would either complicate reviews, or at risk of being controversial:

• Cleanup CanvasParentResizePlugin (Update winit dependency to 0.29 #10702 (comment))
  • Remove CanvasParentResizePlugin Remove CanvasParentResizePlugin #11057
  • Allow to set canvas properties Winit 0.29 follow up #11052 (comment) ; Remove CanvasParentResizePlugin #11057 (comment)
    • 🚧 WIP: Fix fit_canvas_to_parent #11278
• avoid mentionning explicitly winit in docs from bevy_window ?
• NamedKey integration on bevy_input: Revise Key, KeyCode enums rust-windowing/winit#3143 introduced a new NamedKey variant. I implemented it only on the converters but we'd benefit making the same changes to bevy_input.
• Add more info in KeyboardInput Update winit dependency to 0.29 #10702 (review)
  • Done: Add logical key data to KeyboardInput #11400
  • Update examples to use that feature (context: Add logical key data to KeyboardInput #11400 (comment))
• macOS Sonoma (14.0) / Xcode 15.0 — Compatibility Fixes + Docs #9905 added a workaround on a bug allegedly fixed by winit 0.29. We should check if it's still necessary.
• update to raw_window_handle 0.6
  • Done: Update to wgpu 0.19 and raw-window-handle 0.6 #11280
• Rename KeyCode to PhysicalKeyCode Update winit dependency to 0.29 #10702 (comment)
  • dropped: Rename KeyCode to PhysicalKey #11692
• remove instant dependency, replaced by web_time), we'd need to update to fastrand >= 2.0.
  • With the asset rework we don't depend on fastrand anymore.
• Verify license, see discussion
  • we might be missing a short notice or description of changes made
• Consider using https://github.com/rust-windowing/cursor-icon directly rather than vendoring it in bevy.
• investigate this unwrap (winit_window.canvas().unwrap();)
  • Removed with Use WindowBuilder::with_append() to append canvas #11065
• Call pre_present_notify Winit 0.29 follow up #11052 (comment)
• Use more good things about winit's update
  • KeyCode::key_char #10689 (comment)
  • Take Winit's WindowEvent::Occluded into account #11229

[daxpedda]

• (windows) unreleased winit fix for using set_control_flow in AboutToWait Windows: set_control_flow has no effect from AboutToWait event rust-windowing/winit#3215 ; ⚠️ I'm not sure what the implications are, but that feels bad 🤔

This has been addressed in Winit v0.29.4.

• investigate this unwrap (winit_window.canvas().unwrap();)

See #10702 (comment).

EDIT: This part of the code will go away in #11065.

---

One thing I believe was overlooked is the missing documentation on setting a CSS size on the canvas. This will become a major footgun for any deployments targeting any platform with a scale factor that's not 1.0.

FWIW: Window::fit_canvas_to_parent was still useful to apply the CSS width: 100%; height: 100%, something similar should be introduced again (without all the resizing stuff, it should literally only apply these CSS values).

[rniii]

Could that property be bought back for setting the CSS? Right now, the canvas seems to still get an inline style with width/height (and max-/min-) set, so you also need to use !important on your stylesheet.

Another thing that seems to have went unnoticed is that canvas elements default to display: inline, which causes them to not exactly fit in the parent element and overflow, so this option could also add display: block (or it could be always there).

Either way, I do agree it should be at least documented if not added.

[daxpedda]

I didn't review #10702, but looking at it now there is at least one big problem: AboutToWait is used to update and draw. This can't work unfortunately, because AboutToWait has no relationship with time or drawing or anything really, it's wholly dependent on user input and other various events, it could fire once per second or a million times.

EDIT: I looked into it a bit further, and as far as I can see Bevy has some system in place to update based on RedrawRequested, but still do the redrawing in AboutToWait. This could be fine, but unfortunately I couldn't find any reference to WindowEvent::RedrawRequested, so I assume that this was missed during the update.

The only meaning ascribed to it should be that there are currently no further events. It is recommended to draw either based on your own timings (maybe in combination with ControlFlow::WaitUntil), or simply use Window::request_redraw(), which has to be called every frame to queue the next one, and then draw on RedrawRequested.

If Bevy wants to also update exactly as fast as it draws, then it can do the update in RedrawRequested as well.

My assumption is that this is the culprit behind #11122 and rust-windowing/winit#1418 (which is linked by a bunch of Bevy issues).

Please feel free to tag me at any Winit related issues/PRs, I'm happy to chime in or review them.