-
Notifications
You must be signed in to change notification settings - Fork 950
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
Coroutines #412
Closed
Closed
Coroutines #412
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
poll_events() and run_forever() now delegate event production to get_event(), a new function whose job it is to either a) produce Some(Event) by a Timeout or b) return None. This dramatically simplifies the entire event loop. MacOS in particular has multiple ways that Events can be produced: wakeup(), AppDelegate callbacks, and a Cocoa event receive -> send -> translate cycle. The first two are handled by an event queue; wakeup() now posts an Event::Awakened to the queue, just like the callbacks. The CocoaEvent cycle is handled either via the usual blocking [NSApp sendEvent:] call or via a coroutine-based event dispatcher. The coroutine yields back to get_event() on a regular basis, even while it's in the middle of sending events. This allows get_event() to return an event to the calling application even if it is still in the middle of a sendEvent: call.
events_loop::runloop is now responsible for the entire Cocoa runloop cycle. It's a simple blocking implementation (which fails during a resize), but it's an API that maps cleanly to a coroutine-based implementation. NSEvent concerns are now separated into events_loop::nsevent.
This puts an upper bound on how long the coroutine can execute without yielding back to the main thread. The runloop observer fires before going to sleep, which is useful if `forward_event_to_cocoa()` has triggered an inner event loop. The timer could be used to wake the event loop from a different thread, but in practice that has a few milliseconds of latency, and it also requires finding a reference to the timer from `Runloop::wake()`. Instead, the timer is configured to fire every few milliseconds all the time, again in the pursuit of lower latency.
Posting an event causes receive_event_from_cocoa() to return, which gives the runloop an opportunity to check Shared::has_queued_events(). This ensures that wakeup events can be delivered promptly in the absence of other event traffic.
madsmtm
pushed a commit
to madsmtm/winit
that referenced
this pull request
Jun 11, 2022
* feat: connect mouse wheel event with GTK window * Update mouse-wheel.md Co-authored-by: Ngo Iok Ui (Wu Yu Wei) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.