mirror of
https://github.com/rust-windowing/winit.git
synced 2026-06-26 22:53:15 -04:00
ae7497e18f
The idea that redraw events are dispatched with a specific ordering that makes it possible to specifically report when we have finished dispatching redraw events isn't portable and the way in which we dispatched RedrawEventsCleared was inconsistent across backends. More generally speaking, there is no inherent relationship between redrawing and event loop iterations. An event loop may wake up at any frequency depending on what sources of input events are being listened to but redrawing is generally throttled and in some way synchronized with the display frequency. Similarly there's no inherent relationship between a single event loop iteration and the dispatching of any specific kind of "main" event. An event loop wakes up when there are events to read (e.g. input events or responses from a display server / compositor) and goes back to waiting when there's nothing else to read. There isn't really a special kind of "main" event that is dispatched in order with respect to other events. What we can do more portably is emit an event when the event loop is about to block and wait for new events. In practice this is very similar to how MainEventsCleared was implemented except it wasn't the very last event previously since redraw events could be dispatched afterwards. The main backend where we don't strictly know when we're going to wait for events is Web (since the real event loop is internal to the browser). For now we emulate AboutToWait on Web similar to how MainEventsCleared was dispatched. In practice most applications almost certainly shouldn't care about AboutToWait because the frequency of event loop iterations is essentially arbitrary and usually irrelevant.
163 lines
7.1 KiB
Rust
163 lines
7.1 KiB
Rust
//! Winit is a cross-platform window creation and event loop management library.
|
|
//!
|
|
//! # Building windows
|
|
//!
|
|
//! Before you can build a [`Window`], you first need to build an [`EventLoop`]. This is done with the
|
|
//! [`EventLoop::new()`] function.
|
|
//!
|
|
//! ```no_run
|
|
//! use winit::event_loop::EventLoop;
|
|
//! let event_loop = EventLoop::new();
|
|
//! ```
|
|
//!
|
|
//! Once this is done there are two ways to create a [`Window`]:
|
|
//!
|
|
//! - Calling [`Window::new(&event_loop)`][window_new].
|
|
//! - Calling [`let builder = WindowBuilder::new()`][window_builder_new] then [`builder.build(&event_loop)`][window_builder_build].
|
|
//!
|
|
//! The first method is the simplest, and will give you default values for everything. The second
|
|
//! method allows you to customize the way your [`Window`] will look and behave by modifying the
|
|
//! fields of the [`WindowBuilder`] object before you create the [`Window`].
|
|
//!
|
|
//! # Event handling
|
|
//!
|
|
//! Once a [`Window`] has been created, it will generate different *events*. A [`Window`] object can
|
|
//! generate [`WindowEvent`]s when certain input events occur, such as a cursor moving over the
|
|
//! window or a key getting pressed while the window is focused. Devices can generate
|
|
//! [`DeviceEvent`]s, which contain unfiltered event data that isn't specific to a certain window.
|
|
//! Some user activity, like mouse movement, can generate both a [`WindowEvent`] *and* a
|
|
//! [`DeviceEvent`]. You can also create and handle your own custom [`UserEvent`]s, if desired.
|
|
//!
|
|
//! You can retrieve events by calling [`EventLoop::run`][event_loop_run]. This function will
|
|
//! dispatch events for every [`Window`] that was created with that particular [`EventLoop`], and
|
|
//! will run until the `control_flow` argument given to the closure is set to
|
|
//! [`ControlFlow`]`::`[`ExitWithCode`] (which [`ControlFlow`]`::`[`Exit`] aliases to), at which
|
|
//! point [`Event`]`::`[`LoopExiting`] is emitted and the entire program terminates.
|
|
//!
|
|
//! Winit no longer uses a `EventLoop::poll_events() -> impl Iterator<Event>`-based event loop
|
|
//! model, since that can't be implemented properly on some platforms (e.g web, iOS) and works poorly on
|
|
//! most other platforms. However, this model can be re-implemented to an extent with
|
|
//! [`EventLoopExtPumpEvents::pump_events`]. See that method's documentation for more reasons about why
|
|
//! it's discouraged, beyond compatibility reasons.
|
|
//!
|
|
//!
|
|
//! ```no_run
|
|
//! use winit::{
|
|
//! event::{Event, WindowEvent},
|
|
//! event_loop::EventLoop,
|
|
//! window::WindowBuilder,
|
|
//! };
|
|
//!
|
|
//! let event_loop = EventLoop::new();
|
|
//! let window = WindowBuilder::new().build(&event_loop).unwrap();
|
|
//!
|
|
//! event_loop.run(move |event, _, control_flow| {
|
|
//! // ControlFlow::Poll continuously runs the event loop, even if the OS hasn't
|
|
//! // dispatched any events. This is ideal for games and similar applications.
|
|
//! control_flow.set_poll();
|
|
//!
|
|
//! // ControlFlow::Wait pauses the event loop if no events are available to process.
|
|
//! // This is ideal for non-game applications that only update in response to user
|
|
//! // input, and uses significantly less power/CPU time than ControlFlow::Poll.
|
|
//! control_flow.set_wait();
|
|
//!
|
|
//! match event {
|
|
//! Event::WindowEvent {
|
|
//! event: WindowEvent::CloseRequested,
|
|
//! ..
|
|
//! } => {
|
|
//! println!("The close button was pressed; stopping");
|
|
//! control_flow.set_exit();
|
|
//! },
|
|
//! Event::AboutToWait => {
|
|
//! // Application update code.
|
|
//!
|
|
//! // Queue a RedrawRequested event.
|
|
//! //
|
|
//! // You only need to call this if you've determined that you need to redraw, in
|
|
//! // applications which do not always need to. Applications that redraw continuously
|
|
//! // can just render here instead.
|
|
//! window.request_redraw();
|
|
//! },
|
|
//! Event::RedrawRequested(_) => {
|
|
//! // Redraw the application.
|
|
//! //
|
|
//! // It's preferable for applications that do not render continuously to render in
|
|
//! // this event rather than in AboutToWait, since rendering in here allows
|
|
//! // the program to gracefully handle redraws requested by the OS.
|
|
//! },
|
|
//! _ => ()
|
|
//! }
|
|
//! });
|
|
//! ```
|
|
//!
|
|
//! [`Event`]`::`[`WindowEvent`] has a [`WindowId`] member. In multi-window environments, it should be
|
|
//! compared to the value returned by [`Window::id()`][window_id_fn] to determine which [`Window`]
|
|
//! dispatched the event.
|
|
//!
|
|
//! # Drawing on the window
|
|
//!
|
|
//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However it allows you to
|
|
//! retrieve the raw handle of the window and display (see the [`platform`] module and/or the
|
|
//! [`raw_window_handle`] and [`raw_display_handle`] methods), which in turn allows
|
|
//! you to create an OpenGL/Vulkan/DirectX/Metal/etc. context that can be used to render graphics.
|
|
//!
|
|
//! Note that many platforms will display garbage data in the window's client area if the
|
|
//! application doesn't render anything to the window by the time the desktop compositor is ready to
|
|
//! display the window to the user. If you notice this happening, you should create the window with
|
|
//! [`visible` set to `false`](crate::window::WindowBuilder::with_visible) and explicitly make the
|
|
//! window visible only once you're ready to render into it.
|
|
//!
|
|
//! [`EventLoop`]: event_loop::EventLoop
|
|
//! [`EventLoopExtPumpEvents::pump_events`]: ./platform/pump_events/trait.EventLoopExtPumpEvents.html#tymethod.pump_events
|
|
//! [`EventLoop::new()`]: event_loop::EventLoop::new
|
|
//! [event_loop_run]: event_loop::EventLoop::run
|
|
//! [`ControlFlow`]: event_loop::ControlFlow
|
|
//! [`Exit`]: event_loop::ControlFlow::Exit
|
|
//! [`ExitWithCode`]: event_loop::ControlFlow::ExitWithCode
|
|
//! [`Window`]: window::Window
|
|
//! [`WindowId`]: window::WindowId
|
|
//! [`WindowBuilder`]: window::WindowBuilder
|
|
//! [window_new]: window::Window::new
|
|
//! [window_builder_new]: window::WindowBuilder::new
|
|
//! [window_builder_build]: window::WindowBuilder::build
|
|
//! [window_id_fn]: window::Window::id
|
|
//! [`Event`]: event::Event
|
|
//! [`WindowEvent`]: event::WindowEvent
|
|
//! [`DeviceEvent`]: event::DeviceEvent
|
|
//! [`UserEvent`]: event::Event::UserEvent
|
|
//! [`LoopExiting`]: event::Event::LoopExiting
|
|
//! [`platform`]: platform
|
|
//! [`raw_window_handle`]: ./window/struct.Window.html#method.raw_window_handle
|
|
//! [`raw_display_handle`]: ./window/struct.Window.html#method.raw_display_handle
|
|
|
|
#![deny(rust_2018_idioms)]
|
|
#![deny(rustdoc::broken_intra_doc_links)]
|
|
#![deny(clippy::all)]
|
|
#![cfg_attr(feature = "cargo-clippy", deny(warnings))]
|
|
// Doc feature labels can be tested locally by running RUSTDOCFLAGS="--cfg=docsrs" cargo +nightly doc
|
|
#![cfg_attr(docsrs, feature(doc_auto_cfg))]
|
|
#![allow(clippy::missing_safety_doc)]
|
|
|
|
#[allow(unused_imports)]
|
|
#[macro_use]
|
|
extern crate log;
|
|
#[cfg(feature = "serde")]
|
|
#[macro_use]
|
|
extern crate serde;
|
|
#[macro_use]
|
|
extern crate bitflags;
|
|
|
|
pub mod dpi;
|
|
#[macro_use]
|
|
pub mod error;
|
|
pub mod event;
|
|
pub mod event_loop;
|
|
mod icon;
|
|
pub mod keyboard;
|
|
pub mod monitor;
|
|
mod platform_impl;
|
|
pub mod window;
|
|
|
|
pub mod platform;
|