-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Add WinitEvent aggregate event for synchronized window event reading #12100
Conversation
I think that even if we add timestamps to input events, this is still worth having around. It saves users from having to reconstitute this event stream themselves. |
I am getting |
WindowEvent::KeyboardInput { ref event, .. } => { | ||
if event.state.is_pressed() { | ||
if let Some(char) = &event.text { | ||
let char = char.clone(); | ||
app.send_event(ReceivedCharacter { window, char }); | ||
winit_events.send(ReceivedCharacter { window, char }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're no longer using those other event types, can we remove them? or are we to double-send events along both queues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah events are double-sent now, events are dispatched before each app update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a very welcome change, thank you.
My only suggestions would be to send the events directly into the app, instead of allocating an independent Vec
and running the newly added flush function. That should allow the app's internal event resource to only pay price of allocation once, instead of every event loop. This adds an entry to the existing event_writer_system_state
, and cuts about 70 LOC. I opened a PR against this PR with those changes here: UkoeHB#1
The
The PR you opened removes the step where you forward WinitEvents as individual events to Bevy, which will not pass CI. I agree that your solution feels a bit cleaner, but I'm not sure how you would forward winit events properly using that approach. |
Yup, you're right, I always get a bit confused following the control flow of the runner/event loop. 😄
Maybe I missed something, but in the PR, I'm accessing the |
Yep and that works great for the aggregate |
Yes, I missed that. Thanks again for getting this change in, looking forward to properly ordered input events! |
…evyengine#12100) # Objective - Allow users to read window events in the sequence they appeared. This is important for precise input handling when there are multiple input events in a single frame (e.g. click and release vs release and click). ## Solution - Add a mega-enum `WinitEvent` that collects window events, and send those alongside the existing more granular window events. --- ## Changelog - Added `WinitEvent` event that aggregates all window events into a synchronized event stream.
# Objective - CI is green ## Solution - Fix typos (bevyengine#12045) - Correctly declare features (bevyengine#12100)
In what release will this land? The milestone is not set |
By default merged PRs are shipped in the next major version of Bevy. In this case, 0.14 :) |
Gotcha! |
Objective
Solution
WinitEvent
that collects window events, and send those alongside the existing more granular window events.Changelog
WinitEvent
event that aggregates all window events into a synchronized event stream.