pub enum Event<'a, T: 'static> {
NewEvents(StartCause),
WindowEvent {
window_id: WindowId,
event: WindowEvent<'a>,
},
DeviceEvent {
device_id: DeviceId,
event: DeviceEvent,
},
UserEvent(T),
Suspended,
Resumed,
MainEventsCleared,
RedrawRequested(WindowId),
RedrawEventsCleared,
LoopDestroyed,
}Expand description
Describes a generic event.
See the module-level docs for more information on the event loop manages each event.
Variants§
NewEvents(StartCause)
Emitted when new events arrive from the OS to be processed.
This event type is useful as a place to put code that should be done before you start
processing events, such as updating frame timing information for benchmarking or checking
the StartCause to see if a timer set by
ControlFlow::WaitUntil has elapsed.
WindowEvent
Emitted when the OS sends an event to a winit window.
DeviceEvent
Emitted when the OS sends an event to a device.
UserEvent(T)
Emitted when an event is sent from EventLoopProxy::send_event
Suspended
Emitted when the application has been suspended.
Portability
Not all platforms support the notion of suspending applications, and there may be no
technical way to guarantee being able to emit a Suspended event if the OS has
no formal application lifecycle (currently only Android and iOS do). For this reason,
Winit does not currently try to emit pseudo Suspended events before the application
quits on platforms without an application lifecycle.
Considering that the implementation of Suspended and Resumed events may be internally
driven by multiple platform-specific events, and that there may be subtle differences across
platforms with how these internal events are delivered, it’s recommended that applications
be able to gracefully handle redundant (i.e. back-to-back) Suspended or Resumed events.
Also see Resumed notes.
Android
On Android, the Suspended event is only sent when the application’s associated
SurfaceView is destroyed. This is expected to closely correlate with the onPause
lifecycle event but there may technically be a discrepancy.
Applications that need to run on Android should assume their SurfaceView has been
destroyed, which indirectly invalidates any existing render surfaces that may have been
created outside of Winit (such as an EGLSurface, VkSurfaceKHR or wgpu::Surface).
After being Suspended on Android applications must drop all render surfaces before
the event callback completes, which may be re-created when the application is next Resumed.
iOS
On iOS, the Suspended event is currently emitted in response to an
applicationWillResignActive callback which means that the application is
about to transition from the active to inactive state (according to the
iOS application lifecycle).
Resumed
Emitted when the application has been resumed.
For consistency, all platforms emit a Resumed event even if they don’t themselves have a
formal suspend/resume lifecycle. For systems without a standard suspend/resume lifecycle
the Resumed event is always emitted after the NewEvents(StartCause::Init)
event.
Portability
It’s recommended that applications should only initialize their graphics context and create
a window after they have received their first Resumed event. Some systems
(specifically Android) won’t allow applications to create a render surface until they are
resumed.
Considering that the implementation of Suspended and Resumed events may be internally
driven by multiple platform-specific events, and that there may be subtle differences across
platforms with how these internal events are delivered, it’s recommended that applications
be able to gracefully handle redundant (i.e. back-to-back) Suspended or Resumed events.
Also see Suspended notes.
Android
On Android, the Resumed event is sent when a new SurfaceView has been created. This is
expected to closely correlate with the onResume lifecycle event but there may technically
be a discrepancy.
Applications that need to run on Android must wait until they have been Resumed
before they will be able to create a render surface (such as an EGLSurface,
VkSurfaceKHR or wgpu::Surface) which depend on having a
SurfaceView. Applications must also assume that if they are Suspended, then their
render surfaces are invalid and should be dropped.
Also see Suspended notes.
iOS
On iOS, the Resumed event is emitted in response to an applicationDidBecomeActive
callback which means the application is “active” (according to the
iOS application lifecycle).
MainEventsCleared
Emitted when all of the event loop’s input events have been processed and redraw processing is about to begin.
This event is useful as a place to put your code that should be run after all
state-changing events have been handled and you want to do stuff (updating state, performing
calculations, etc) that happens as the “main body” of your event loop. If your program only draws
graphics when something changes, it’s usually better to do it in response to
Event::RedrawRequested, which gets emitted
immediately after this event. Programs that draw graphics continuously, like most games,
can render here unconditionally for simplicity.
RedrawRequested(WindowId)
Emitted after MainEventsCleared when a window should be redrawn.
This gets triggered in two scenarios:
- The OS has performed an operation that’s invalidated the window’s contents (such as resizing the window).
- The application has explicitly requested a redraw via
Window::request_redraw.
During each iteration of the event loop, Winit will aggregate duplicate redraw requests into a single event, to help avoid duplicating rendering work.
Mainly of interest to applications with mostly-static graphics that avoid redrawing unless something changes, like most non-game GUIs.
Platform-specific
- macOS / iOS: Due to implementation difficulties, this will often, but not always, be
emitted directly inside
drawRect:, with neither a precedingMainEventsClearednor subsequentRedrawEventsCleared. See #2640 for work on this.
RedrawEventsCleared
Emitted after all RedrawRequested events have been processed and control flow is about to
be taken away from the program. If there are no RedrawRequested events, it is emitted
immediately after MainEventsCleared.
This event is useful for doing any cleanup or bookkeeping work after all the rendering tasks have been completed.
LoopDestroyed
Emitted when the event loop is being shut down.
This is irreversible - if this event is emitted, it is guaranteed to be the last event that gets emitted. You generally want to treat this as an “do on quit” event.