Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update winit dependency to 0.29 #8745

Closed
wants to merge 45 commits into from
Closed

Conversation

Vrixyz
Copy link
Member

@Vrixyz Vrixyz commented Jun 2, 2023

⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️
⚠️ Closed in favor of #10702 ⚠️
⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️

#10702 only builds on this PR but without obsolete comments and discussions.

Objective

  • Update winit dependency to 0.29

Changelog

  • Changed most KeyCode values, they now represent physical keys (and could infer their scancode) rather than logical
    • Behind other PR: new KeyLogic::Logic(Key), with "regular" characters behind a SmolStr.
  • Use web-time rather than instant crate. (Replace instant with web-time rust-windowing/winit#2836)
  • winit did split run_return in run_onDemand and pump_events, I did the same change in bevy_winit and used pump_events.
  • Removed return_from_run from WinitSettings as winit::run now returns on supported platforms.

Call for help

Answered interrogations

API complexity

I'm not sure about this new API, it seems cumbersome to do #8745 (comment)

- keycode.is_pressed(KeyCode::KeyQ)
+ key.is_pressed(Key::Character("q".into()))
  • ✅ Leverage Into to support key.is_pressed("q")

Copy incompatible with SmolStr

We should add a logical Key based on winit's Key, but bevy's KeyboardInput is Copy, but SmolStr is not, so I'm not sure how to proceed ?

  • remove Copy ? I feel like it's a bad idea because events are usually Copy.
    • ✅ remove copy when problematic
  • use Cow or something..?
    • ✅ use SmolStr with added reflection
  • add Copy upstream to SmolStr (I think that won't pass, if at all possible)
  • use another type ? plain String...
  • use our curated list of supported characters/string as enum, but that doesn't sound great (because chinese characters, copy/paste/IME probably wouldn't be supported this way.
  • ✅ stick to copying winit's types as much as possible

Blockers

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 one this PR is closed:

Migration Guide

This PR should have one.

@Vrixyz Vrixyz changed the title Update winit to main Update winit dependency to main Jun 2, 2023
@alice-i-cecile alice-i-cecile added this to the 0.11 milestone Jun 2, 2023
@alice-i-cecile alice-i-cecile added A-Windowing Platform-agnostic interface layer to run your app in C-Dependencies A change to the crates that Bevy depends on M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide labels Jun 2, 2023
@alice-i-cecile
Copy link
Member

We should add a logical Key based on winit's Key, but bevy's KeyboardInput is Copy, but SmolStr is not, so I'm not sure how to proceed ?

IMO we should probably just remove the Copy bound here. Exposing this information is important, and all the other workarounds are worse than just having to call .clone().

@daxpedda
Copy link
Contributor

daxpedda commented Jun 3, 2023

The Web backend in Winit had quite a bit of churn lately, let me know if you uncover any bugs or issues.

@Vrixyz
Copy link
Member Author

Vrixyz commented Jun 3, 2023

with 54483f9, I'm exploring:

  • For logical key, I make bevy_input declare a Key<String> populated from winit's Key<SmolStr>, it's easier to implement for me so I don't get FromReflect errors because of SmolStr.
  • In KeyboardInput, ^ That logical key is now a field logical_key: Key, and replaces key_code: ScanCode
  • The type ScanCode is replaced by a KeyCode, and rename KeyboardInput's scan_code to key_code
    • ⚠️ I think it's wrong because for bevy user's perspective it means key_code switches from being the logical key to the physical key, and could be missed. That makes our wording more consistent with winit's though.

@Vrixyz
Copy link
Member Author

Vrixyz commented Jun 3, 2023

IMO we should probably just remove the Copy bound here. Exposing this information is important, and all the other workarounds are worse than just having to call .clone().

Unfortunately this option proves to be difficult, bevy's input system involves app.init_resource::<Input<Key>>(), where Input<T:Copy>, I'm not sure how to proceed. (we can remove Copy from Input, would that be accepted?)

@alice-i-cecile
Copy link
Member

Removing the Copy bound from Input is totally fine: I don't think there's a strong reason to require that.

Vrixyz added a commit to Vrixyz/bevy that referenced this pull request Jun 6, 2023
@alice-i-cecile alice-i-cecile added the S-Blocked This cannot move forward until something else changes label Jun 7, 2023
alice-i-cecile added a commit that referenced this pull request Jun 8, 2023
# Objective
To upgrade winit's dependency, it's useful to reuse SmolStr, which
replaces/improves the too restrictive Key letter enums.

As Input<Key> is a resource it should implement Reflect through all its
fields.

## Solution

Add smol_str to bevy_reflect supported types, behind a feature flag.

This PR blocks winit's upgrade PR:
#8745.

# Current state

- I'm discovering bevy_reflect, I appreciate all feedbacks, and send me
your nitpicks!
- Lacking more tests

---------

Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Gino Valente <[email protected]>
@Vrixyz
Copy link
Member Author

Vrixyz commented Jun 8, 2023

@alice-i-cecile I think this PR can be removed from 0.11 milestone, because winit doesn't plan to release 0.29 until august.

@mockersf mockersf removed this from the 0.11 milestone Jun 8, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2023

Example alien_cake_addict failed to run, please try running it locally and check the result.

1 similar comment
@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2023

Example alien_cake_addict failed to run, please try running it locally and check the result.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2023

Example alien_cake_addict failed to run, please try running it locally and check the result.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2023

Example alien_cake_addict failed to run, please try running it locally and check the result.

@alice-i-cecile alice-i-cecile removed the S-Blocked This cannot move forward until something else changes label Oct 22, 2023
@alice-i-cecile
Copy link
Member

No longer blocked following the winit 0.29 release 🎉

@simbleau
Copy link
Contributor

simbleau commented Oct 25, 2023

🙏

@Vrixyz for those who may stuble upon this, how is this issue/pr related to fixing the bevy_egui issue where non-qwerty keyboards can't type symbols or special characters on wasm32?

@Vrixyz Vrixyz mentioned this pull request Oct 25, 2023
github-merge-queue bot pushed a commit that referenced this pull request Oct 25, 2023
few format tweaks, initially spotted working on
#8745
@Vrixyz
Copy link
Member Author

Vrixyz commented Oct 27, 2023

🙏

@Vrixyz for those who may stuble upon this, how is this issue/pr related to fixing the bevy_egui issue where non-qwerty keyboards can't type symbols or special characters on wasm32?

To answer "in short": I tracked it to the example char_input_events on bevy wasm, and noticed such special characters were not printed. winit refactored the keyboard input and I believe that's a good step towards fixing that issue.

For a longer context: vladbat00/bevy_egui#178 (comment) -> this doesn't explicitly mentions special characters but it's a bit all related (other recap of the context here: https://thierryberger.com/drafts/contribution-story-winit/)

ameknite pushed a commit to ameknite/bevy that referenced this pull request Nov 6, 2023
few format tweaks, initially spotted working on
bevyengine#8745
@Vrixyz
Copy link
Member Author

Vrixyz commented Nov 8, 2023

No longer blocked following the winit 0.29 release 🎉

For exactness, we were still blocked by accesskit, but it's not longer the case following https://github.com/AccessKit/accesskit/releases/tag/accesskit_winit-v0.16.0 🎉

@tim-blackbird
Copy link
Contributor

futures-lite has also updated to fastrand 2.0 since

Copy link
Contributor

@tim-blackbird tim-blackbird left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed! This is a great step forward for input handling c:

converters::convert_keyboard_input(event, window_entity);
if let bevy_input::keyboard::Key::Character(c) = &keyboard_event.logical_key
{
if let Some(first_char) = c.chars().next() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is sending only the first character correct here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I.. guess not, but sending the whole SmolStr within ReceivedCharacter seemed a big change when I was on it.

I can see multiple solutions:

  • sending SmolStr.
  • sending several ReceivedCharacter(char)
  • splitting ReceivedCharacter and ReceivedMultipleCharacters ?

I thought this implementation was the closest to current main behaviour, so that might be OK as a first approach.
I'm writing that in "Follow Up" for the time being.

Comment on lines 596 to 598
if inner_size_writer.request_inner_size(new_inner_size).is_ok() {
new_inner_size = maybe_new_inner_size;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it makes sense to log the failure case here.

crates/bevy_winit/src/lib.rs Outdated Show resolved Hide resolved
} else {
run(event_loop, event_handler);
}
let _ = run(event_loop, event_handler);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should log the error here.

@@ -174,7 +174,7 @@ pub(crate) fn changed_windows(
window.resolution.physical_width(),
window.resolution.physical_height(),
);
winit_window.set_inner_size(physical_size);
let _ = winit_window.request_inner_size(physical_size);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we should handle this returning Some. From the docs:

On platforms where the size is entirely controlled by the user the applied size will be returned immediately, resize event in such case may not be generated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(link to docs)
" may not be generated " 🙁 ; I don't like uncertainty...

this seems to only affect wayland? ; but the exact path to the maybe not generated event is quite hard to follow 🤔...

I'll follow the trail to winit and might open an issue because I'd like to handle differently:

  • Some(newValue): generate an event resize like we do when reacting from events ⚠️ the "may" from the docs may cause the event to be sent twice.
  • Some(oldValue): do not generate an event resize ⚠️ I cannot differentiate it from a new value, so I'd send "useless" resize. Well I guess we're not supposed to send a resize event in those platforms anyway but still.
  • None: event will be sent afterward, or not ✅

maybe the docs is wrong and should read "will not be generated", so I can handle it with certainty 🤞.

Copy link
Member Author

@Vrixyz Vrixyz Nov 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bringing up resizing, my PR has a regression, as window is not redrawn during resizing.

My PR

(rev aaa3368)

resizing_PR_8745.mp4

On main

(rev 0cc1179)

resizing_main_0cc11791b9a55f5d310ee754c9f7254081e7138a.mp4

@@ -194,7 +194,7 @@ impl WinitWindows {
use winit::platform::web::WindowExtWebSys;

if window.canvas.is_none() {
let canvas = winit_window.canvas();
let canvas = winit_window.canvas().unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs for this state

Only returns the canvas if called from inside the window.

I'm not sure what that means.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's alright to call unwrap on that, I believe it's instantiated at the same time of a window, so it might fail if you're doing convoluted things like modifying the canvas from javascript.

But that's not a rabbit hole I'm ready to follow yet. I'll make a note about it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only returns the canvas if called from inside the window.

Apparently this didn't turn out very clear. This will only return None if called from a Web worker, it will always succeed if called from the "main thread" (the "window" context).

//! - <https://docs.rs/bevy/latest/bevy/winit/struct.WinitSettings.html#structfield.return_from_run>
//! not recommended because:
//! - `App::run()` will never return on iOS and Web.
//! - It is not possible to recreate a window afer the event loop has been terminated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now a Bevy limitation, not winit's, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if keyboard_input.just_pressed(KeyCode::Plus) {
if keyboard_input.just_pressed(KeyCode::NumpadAdd) {
Copy link
Contributor

@tim-blackbird tim-blackbird Nov 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's up with Plus? Did it become Equal? but Equals already existed, hmmm

Not everyone has a numpad though, so should we use something else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure; I'll use equal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were swapped in winit by mistake IIRC :(

Comment on lines +621 to +622
// TOCLEAN: Thierry: this is originally SmolStr, but difficult to translate to FromReflect.
Web(SmolStr),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment up-to-date?

/// Program busy indicator.
Wait,
/// Help indicator (often rendered as a "?")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about all these empty lines.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to be as similar as the source, which was updated this way: https://github.com/rust-windowing/cursor-icon/blob/main/src/lib.rs

as cursor-icon was given its own dependency, maybe we could rely on that directly rather than copying it?

Also, licensing is probably not respected (and maybe other places too (see PR description "Call for help")), so I'm happy to discuss a better way of handling that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copying the message in winit's 'keyboard.rs' verbatim to our 'keyboard.rs' file(Where Key and KeyCode are defined) will satisfy the W3C license :)

Copy link
Member Author

@Vrixyz Vrixyz Nov 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from https://www.w3.org/copyright/software-license-2002/ ; I think we'd need to also include the changes made. they are pretty straightforward:

  • add Reflect capabilities
  • use another feature name for serialization
  • maybe not using non_exhaustive for enums?

But I lack knowledge on how to write that. I'll copy the licenses as I believe it's better than nothing :)

image

@Vrixyz
Copy link
Member Author

Vrixyz commented Nov 22, 2023

I'm closing this PR in favor of #10702 ; which builds on this one but it's time to get a shorter comment thread

@Vrixyz Vrixyz closed this Nov 22, 2023
github-merge-queue bot pushed a commit that referenced this pull request Dec 21, 2023
# Objective

- Update winit dependency to 0.29

## Changelog

### KeyCode changes

- Removed `ScanCode`, as it was [replaced by
KeyCode](https://github.com/rust-windowing/winit/blob/master/CHANGELOG.md#0292).
- `ReceivedCharacter.char` is now a `SmolStr`, [relevant
doc](https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html#structfield.text).
- Changed most `KeyCode` values, and added more.

KeyCode has changed meaning. With this PR, it refers to physical
position on keyboard rather than the printed letter on keyboard keys.

In practice this means:
- On QWERTY keyboard layouts, nothing changes
- On any other keyboard layout, `KeyCode` no longer reflects the label
on key.
- This is "good". In bevy 0.12, when you used WASD for movement, users
with non-QWERTY keyboards couldn't play your game! This was especially
bad for non-latin keyboards. Now, WASD represents the physical keys. A
French player will press the ZQSD keys, which are near each other,
Kyrgyz players will use "Цфыв".
- This is "bad" as well. You can't know in advance what the label of the
key for input is. Your UI says "press WASD to move", even if in reality,
they should be pressing "ZQSD" or "Цфыв". You also no longer can use
`KeyCode` for text inputs. In any case, it was a pretty bad API for text
input. You should use `ReceivedCharacter` now instead.

### Other changes
- Use `web-time` rather than `instant` crate.
(rust-windowing/winit#2836)
- winit did split `run_return` in `run_onDemand` and `pump_events`, I
did the same change in bevy_winit and used `pump_events`.
- Removed `return_from_run` from `WinitSettings` as `winit::run` now
returns on supported platforms.
- I left the example "return_after_run" as I think it's still useful.
- This winit change is done partly to allow to create a new window after
quitting all windows: emilk/egui#1918 ; this
PR doesn't address.
- added `width` and `height` properties in the `canvas` from wasm
example
(#10702 (comment))

## Known regressions (important follow ups?)
- 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 .
- We don't receive characters through alt+numpad (e.g. alt + 151 = "ù")
anymore ; reproduced on winit example "ime". maybe related to
rust-windowing/winit#2945
- (windows) Window content doesn't refresh at all when resizing. By
reading 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 rust-windowing/winit#3215 ; ⚠️ I'm
not sure what the implications are, but that feels bad 🤔

## 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:
- remove CanvasParentResizePlugin
(#10702 (comment))
- avoid mentionning explicitly winit in docs from bevy_window ?
- NamedKey integration on bevy_input:
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
#10702 (review)
- #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
  - blocked by wgpu
- Rename `KeyCode` to `PhysicalKeyCode`
#10702 (comment)
- remove `instant` dependency, [replaced
by](rust-windowing/winit#2836) `web_time`), we'd
need to update to :
  - fastrand >= 2.0
- [`async-executor`](https://github.com/smol-rs/async-executor) >= 1.7
    - [`futures-lite`](https://github.com/smol-rs/futures-lite) >= 2.0
- Verify license, see
[discussion](#8745 (comment))
  - 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](#8745 (comment))
(`winit_window.canvas().unwrap();`)
- Use more good things about winit's update
- #10689 (comment)
## Migration Guide

This PR should have one.
@Vrixyz Vrixyz mentioned this pull request Dec 21, 2023
23 tasks
rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024
few format tweaks, initially spotted working on
bevyengine#8745
Subserial pushed a commit to Subserial/bevy_winit_hook that referenced this pull request Feb 20, 2024
# Objective

- Update winit dependency to 0.29

## Changelog

### KeyCode changes

- Removed `ScanCode`, as it was [replaced by
KeyCode](https://github.com/rust-windowing/winit/blob/master/CHANGELOG.md#0292).
- `ReceivedCharacter.char` is now a `SmolStr`, [relevant
doc](https://docs.rs/winit/latest/winit/event/struct.KeyEvent.html#structfield.text).
- Changed most `KeyCode` values, and added more.

KeyCode has changed meaning. With this PR, it refers to physical
position on keyboard rather than the printed letter on keyboard keys.

In practice this means:
- On QWERTY keyboard layouts, nothing changes
- On any other keyboard layout, `KeyCode` no longer reflects the label
on key.
- This is "good". In bevy 0.12, when you used WASD for movement, users
with non-QWERTY keyboards couldn't play your game! This was especially
bad for non-latin keyboards. Now, WASD represents the physical keys. A
French player will press the ZQSD keys, which are near each other,
Kyrgyz players will use "Цфыв".
- This is "bad" as well. You can't know in advance what the label of the
key for input is. Your UI says "press WASD to move", even if in reality,
they should be pressing "ZQSD" or "Цфыв". You also no longer can use
`KeyCode` for text inputs. In any case, it was a pretty bad API for text
input. You should use `ReceivedCharacter` now instead.

### Other changes
- Use `web-time` rather than `instant` crate.
(rust-windowing/winit#2836)
- winit did split `run_return` in `run_onDemand` and `pump_events`, I
did the same change in bevy_winit and used `pump_events`.
- Removed `return_from_run` from `WinitSettings` as `winit::run` now
returns on supported platforms.
- I left the example "return_after_run" as I think it's still useful.
- This winit change is done partly to allow to create a new window after
quitting all windows: emilk/egui#1918 ; this
PR doesn't address.
- added `width` and `height` properties in the `canvas` from wasm
example
(bevyengine/bevy#10702 (comment))

## Known regressions (important follow ups?)
- 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 .
- We don't receive characters through alt+numpad (e.g. alt + 151 = "ù")
anymore ; reproduced on winit example "ime". maybe related to
rust-windowing/winit#2945
- (windows) Window content doesn't refresh at all when resizing. By
reading 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 rust-windowing/winit#3215 ; ⚠️ I'm
not sure what the implications are, but that feels bad 🤔

## 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:
- remove CanvasParentResizePlugin
(bevyengine/bevy#10702 (comment))
- avoid mentionning explicitly winit in docs from bevy_window ?
- NamedKey integration on bevy_input:
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
bevyengine/bevy#10702 (review)
- bevyengine/bevy#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
  - blocked by wgpu
- Rename `KeyCode` to `PhysicalKeyCode`
bevyengine/bevy#10702 (comment)
- remove `instant` dependency, [replaced
by](rust-windowing/winit#2836) `web_time`), we'd
need to update to :
  - fastrand >= 2.0
- [`async-executor`](https://github.com/smol-rs/async-executor) >= 1.7
    - [`futures-lite`](https://github.com/smol-rs/futures-lite) >= 2.0
- Verify license, see
[discussion](bevyengine/bevy#8745 (comment))
  - 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](bevyengine/bevy#8745 (comment))
(`winit_window.canvas().unwrap();`)
- Use more good things about winit's update
- bevyengine/bevy#10689 (comment)
## Migration Guide

This PR should have one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Dependencies A change to the crates that Bevy depends on M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants