Skip to content

Commit 9125f44

Browse files
committed
Add EventLoopExtPumpEvents and EventLoopExtRunOnDemand
This adds two new extensions for running a Winit event loop which will replace `EventLoopExtRunReturn` The `run_return` API is trying to solve multiple problems and address multiple, unrelated, use cases but in doing so it is not succeeding at addressing any of them fully. The notable use cases we have are: 1. Applications want to be able to implement their own external event loop and call some Winit API to poll / pump events, once per iteration of their own loop, without blocking the outer, external loop. Addressing rust-windowing#2706 2. Applications want to be able to re-run separate instantiations of some Winit-based GUI and want to allow the event loop to exit with a status, and then later be able to run the loop again for a new instantiation of their GUI. Addressing rust-windowing#2431 It's very notable that these use cases can't be supported across all platforms and so they are extensions, similar to `EventLoopExtRunReturn` The intention is to support these extensions on: - Windows - Linux (X11 + Wayland) - macOS - Android These extensions aren't compatible with Web or iOS though. Each method of running the loop will behave consistently in terms of how `NewEvents(Init)`, `Resumed` and `LoopDestroyed` events are dispatched (so portable application code wouldn't necessarily need to have any awareness of which method of running the loop was being used) Once all backends have support for these extensions then we can remove `EventLoopExtRunReturn` For simplicity, the extensions are documented with the assumption that the above platforms will be supported. This patch makes no functional change, it only introduces these new extensions so we can then handle adding platform-specific backends in separate pull requests, so the work can be landed in stages.
1 parent 66ff52b commit 9125f44

File tree

4 files changed

+271
-0
lines changed

4 files changed

+271
-0
lines changed

src/error.rs

+6
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,10 @@ pub enum ExternalError {
99
NotSupported(NotSupportedError),
1010
/// The OS cannot perform the operation.
1111
Os(OsError),
12+
/// The event loop can't be re-run while it's already running
13+
AlreadyRunning,
14+
/// Application has exit with an error status.
15+
ExitFailure(i32),
1216
}
1317

1418
/// The error type for when the requested operation is not supported by the backend.
@@ -59,8 +63,10 @@ impl fmt::Display for OsError {
5963
impl fmt::Display for ExternalError {
6064
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> Result<(), fmt::Error> {
6165
match self {
66+
ExternalError::AlreadyRunning => write!(f, "EventLoop is already running"),
6267
ExternalError::NotSupported(e) => e.fmt(f),
6368
ExternalError::Os(e) => e.fmt(f),
69+
ExternalError::ExitFailure(status) => write!(f, "Exit Failure: {status}"),
6470
}
6571
}
6672
}

src/event.rs

+8
Original file line numberDiff line numberDiff line change
@@ -329,6 +329,14 @@ pub enum StartCause {
329329
Init,
330330
}
331331

332+
/// The return status for `pump_events`
333+
pub enum PumpStatus {
334+
/// Continue running external loop
335+
Continue,
336+
/// exit external loop
337+
Exit(i32),
338+
}
339+
332340
/// Describes an event from a [`Window`].
333341
#[derive(Debug, PartialEq)]
334342
pub enum WindowEvent<'a> {

src/platform/pump_events.rs

+175
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,175 @@
1+
use crate::{
2+
event::{Event, PumpStatus},
3+
event_loop::{ControlFlow, EventLoop, EventLoopWindowTarget},
4+
};
5+
6+
/// Additional methods on [`EventLoop`] for pumping events within an external event loop
7+
pub trait EventLoopExtPumpEvents {
8+
/// A type provided by the user that can be passed through [`Event::UserEvent`].
9+
type UserEvent;
10+
11+
/// Pump the `EventLoop` to check for and dispatch pending events, without blocking
12+
///
13+
/// This API is designed to enable applications to integrate Winit into an
14+
/// external event loop, for platforms that can support this.
15+
///
16+
/// ```rust,no_run
17+
/// # // Copied from examples/window_pump_events.rs
18+
/// # #[cfg(any(
19+
/// # windows_platform,
20+
/// # macos_platform,
21+
/// # x11_platform,
22+
/// # wayland_platform,
23+
/// # android_platform,
24+
/// # ))]
25+
/// fn main() -> std::process::ExitCode {
26+
/// # use std::{process::ExitCode, thread::sleep, time::Duration};
27+
/// #
28+
/// # use simple_logger::SimpleLogger;
29+
/// # use winit::{
30+
/// # event::{Event, PumpStatus, WindowEvent},
31+
/// # event_loop::EventLoop,
32+
/// # platform::pump_events::EventLoopExtPumpEvents,
33+
/// # window::WindowBuilder,
34+
/// # };
35+
/// let mut event_loop = EventLoop::new();
36+
/// #
37+
/// # SimpleLogger::new().init().unwrap();
38+
/// let window = WindowBuilder::new()
39+
/// .with_title("A fantastic window!")
40+
/// .build(&event_loop)
41+
/// .unwrap();
42+
///
43+
/// 'main: loop {
44+
/// let status = event_loop.pump_events(|event, _, control_flow| {
45+
/// # if let Event::WindowEvent { event, .. } = &event {
46+
/// # // Print only Window events to reduce noise
47+
/// # println!("{event:?}");
48+
/// # }
49+
/// #
50+
/// match event {
51+
/// Event::WindowEvent {
52+
/// event: WindowEvent::CloseRequested,
53+
/// window_id,
54+
/// } if window_id == window.id() => control_flow.set_exit(),
55+
/// Event::MainEventsCleared => {
56+
/// window.request_redraw();
57+
/// }
58+
/// _ => (),
59+
/// }
60+
/// });
61+
/// if let PumpStatus::Exit(exit_code) = status {
62+
/// break 'main ExitCode::from(exit_code as u8);
63+
/// }
64+
///
65+
/// // Sleep for 1/60 second to simulate application work
66+
/// //
67+
/// // Since `pump_events` doesn't block it will be important to
68+
/// // throttle the loop in the app somehow.
69+
/// println!("Update()");
70+
/// sleep(Duration::from_millis(16));
71+
/// }
72+
/// }
73+
/// ```
74+
///
75+
/// **Note:** This is not a portable API, and its usage involves a number of
76+
/// caveats and trade offs that should be considered before using this API!
77+
///
78+
/// You almost certainly shouldn't use this API, unless you absolutely know it's
79+
/// the only practical option you have.
80+
///
81+
/// # Synchronous events
82+
///
83+
/// Some events _must_ only be handled synchronously via the closure that
84+
/// is passed to Winit so that the handler will also be synchronized with
85+
/// the window system and operating system.
86+
///
87+
/// This is because some events are driven by a window system callback
88+
/// where the window systems expects the application to have handled the
89+
/// event before returning.
90+
///
91+
/// **These events can not be buffered and handled outside of the closure
92+
/// passed to Winit**
93+
///
94+
/// As a general rule it is not recommended to ever buffer events to handle
95+
/// them outside of the closure passed to Winit since it's difficult to
96+
/// provide guarantees about which events are safe to buffer across all
97+
/// operating systems.
98+
///
99+
/// Notable events that will certainly create portability problems if
100+
/// buffered and handled outside of Winit include:
101+
/// - `RenderRequested` events, used to schedule rendering.
102+
///
103+
/// macOS for example uses a `drawRect` callback to drive rendering
104+
/// within applications and expects rendering to be finished before
105+
/// the `drawRect` callback returns.
106+
///
107+
/// For portability it's strongly recommended that applications should
108+
/// keep their rendering inside the closure provided to Winit.
109+
/// - Any lifecycle events, such as `Suspended` / `Resumed`.
110+
///
111+
/// The handling of these events needs to be synchronized with the
112+
/// operating system and it would never be appropriate to buffer a
113+
/// notification that your application has been suspended or resumed and
114+
/// then handled that later since there would always be a chance that
115+
/// other lifecycle events occur while the event is buffered.
116+
///
117+
/// # Supported Platforms
118+
/// - Windows
119+
/// - Linux
120+
/// - MacOS
121+
/// - Android
122+
///
123+
/// # Unsupported Platforms
124+
/// - **Web:** This API is fundamentally incompatible with the event-based way in which
125+
/// Web browsers work because it's not possible to have a long-running external
126+
/// loop that would block the browser and there is nothing that can be
127+
/// polled to ask for new new events. Events are delivered via callbacks based
128+
/// on an event loop that is internal to the browser itself.
129+
/// - **iOS:** It's not possible to stop and start an `NSApplication` repeatedly on iOS so
130+
/// there's no way to support the same approach to polling as on MacOS.
131+
///
132+
/// # Platform-specific
133+
/// - **Windows**: The implementation will use `PeekMessage` when checking for
134+
/// window messages to avoid blocking your external event loop.
135+
///
136+
/// - **MacOS**: The implementation works in terms of stopping the global `NSApp`
137+
/// whenever the application `RunLoop` indicates that it is preparing to block
138+
/// and wait for new events.
139+
///
140+
/// This is very different to the polling APIs that are available on other
141+
/// platforms (the lower level polling primitives on MacOS are private
142+
/// implementation details for `NSApp` which aren't accessible to application
143+
/// developers)
144+
///
145+
/// It's likely this will be less efficient than polling on other OSs and
146+
/// it also means the `NSApp` is stopped while outside of the Winit
147+
/// event loop - and that's observable (for example to crates like `rfd`)
148+
/// because the `NSApp` is global state.
149+
///
150+
/// If you render outside of Winit you are likely to see window resizing artifacts
151+
/// since MacOS expects applications to render synchronously during any `drawRect`
152+
/// callback.
153+
fn pump_events<F>(&mut self, event_handler: F) -> PumpStatus
154+
where
155+
F: FnMut(
156+
Event<'_, Self::UserEvent>,
157+
&EventLoopWindowTarget<Self::UserEvent>,
158+
&mut ControlFlow,
159+
);
160+
}
161+
162+
impl<T> EventLoopExtPumpEvents for EventLoop<T> {
163+
type UserEvent = T;
164+
165+
fn pump_events<F>(&mut self, event_handler: F) -> PumpStatus
166+
where
167+
F: FnMut(
168+
Event<'_, Self::UserEvent>,
169+
&EventLoopWindowTarget<Self::UserEvent>,
170+
&mut ControlFlow,
171+
),
172+
{
173+
self.event_loop.pump_events(event_handler)
174+
}
175+
}

src/platform/run_ondemand.rs

+82
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
use crate::{
2+
error::ExternalError,
3+
event::Event,
4+
event_loop::{ControlFlow, EventLoop, EventLoopWindowTarget},
5+
};
6+
7+
#[cfg(doc)]
8+
use crate::{platform::pump_events::EventLoopExtPumpEvents, window::Window};
9+
10+
/// Additional methods on [`EventLoop`] to return control flow to the caller.
11+
pub trait EventLoopExtRunOnDemand {
12+
/// A type provided by the user that can be passed through [`Event::UserEvent`].
13+
type UserEvent;
14+
15+
/// Runs the event loop in the calling thread and calls the given `event_handler` closure
16+
/// to dispatch any window system events.
17+
///
18+
/// Unlike [`EventLoop::run`], this function accepts non-`'static` (i.e. non-`move`) closures
19+
/// and it is possible to return control back to the caller without
20+
/// consuming the `EventLoop` (by setting the `control_flow` to [`ControlFlow::Exit`]) and
21+
/// so the event loop can be re-run after it has exit.
22+
///
23+
/// It's expected that each run of the loop will be for orthogonal instantiations of your
24+
/// Winit application, but internally each instantiation may re-use some common window
25+
/// system resources, such as a display server connection.
26+
///
27+
/// This API is not designed to run an event loop in bursts that you can exit from and return
28+
/// to while maintaining the full state of your application. (If you need something like this
29+
/// you can look at the [`EventLoopExtPumpEvents::pump_events()`] API)
30+
///
31+
/// Each time `run_ondemand` is called the `event_handler` can expect to receive a
32+
/// `NewEvents(Init)` and `Resumed` event (even on platforms that have no suspend/resume
33+
/// lifecycle) - which can be used to consistently initialize application state.
34+
///
35+
/// See the [`ControlFlow`] docs for information on how changes to `&mut ControlFlow` impact the
36+
/// event loop's behavior.
37+
///
38+
/// # Caveats
39+
/// - This extension isn't available on all platforms, since it's not always possible to
40+
/// return to the caller (specifically this is impossible on iOS and Web - though with
41+
/// the Web backend it is possible to use `spawn()` more than once instead).
42+
/// - No [`Window`] state can be carried between separate runs of the event loop.
43+
///
44+
/// You are strongly encouraged to use [`EventLoop::run()`] for portability, unless you specifically need
45+
/// the ability to re-run a single event loop more than once
46+
///
47+
/// # Supported Platforms
48+
/// - Windows
49+
/// - Linux
50+
/// - macOS
51+
/// - Android
52+
///
53+
/// # Unsupported Platforms
54+
/// - **Web:** This API is fundamentally incompatible with the event-based way in which
55+
/// Web browsers work because it's not possible to have a long-running external
56+
/// loop that would block the browser and there is nothing that can be
57+
/// polled to ask for new new events. Events are delivered via callbacks based
58+
/// on an event loop that is internal to the browser itself.
59+
/// - **iOS:** It's not possible to stop and start an `NSApplication` repeatedly on iOS.
60+
fn run_ondemand<F>(&mut self, event_handler: F) -> Result<(), ExternalError>
61+
where
62+
F: FnMut(
63+
Event<'_, Self::UserEvent>,
64+
&EventLoopWindowTarget<Self::UserEvent>,
65+
&mut ControlFlow,
66+
);
67+
}
68+
69+
impl<T> EventLoopExtRunOnDemand for EventLoop<T> {
70+
type UserEvent = T;
71+
72+
fn run_ondemand<F>(&mut self, event_handler: F) -> Result<(), ExternalError>
73+
where
74+
F: FnMut(
75+
Event<'_, Self::UserEvent>,
76+
&EventLoopWindowTarget<Self::UserEvent>,
77+
&mut ControlFlow,
78+
),
79+
{
80+
self.event_loop.run_ondemand(event_handler)
81+
}
82+
}

0 commit comments

Comments
 (0)