2020-04-04 21:59:49 +00:00
|
|
|
mod converters;
|
2023-01-19 00:38:28 +00:00
|
|
|
mod system;
|
Optionally resize Window canvas element to fit parent element (#4726)
Currently Bevy's web canvases are "fixed size". They are manually set to specific dimensions. This might be fine for some games and website layouts, but for sites with flexible layouts, or games that want to "fill" the browser window, Bevy doesn't provide the tools needed to make this easy out of the box.
There are third party plugins like [bevy-web-resizer](https://github.com/frewsxcv/bevy-web-resizer/) that listen for window resizes, take the new dimensions, and resize the winit window accordingly. However this only covers a subset of cases and this is common enough functionality that it should be baked into Bevy.
A significant motivating use case here is the [Bevy WASM Examples page](https://bevyengine.org/examples/). This scales the canvas to fit smaller windows (such as mobile). But this approach both breaks winit's mouse events and removes pixel-perfect rendering (which means we might be rendering too many or too few pixels). https://github.com/bevyengine/bevy-website/issues/371
In an ideal world, winit would support this behavior out of the box. But unfortunately that seems blocked for now: https://github.com/rust-windowing/winit/pull/2074. And it builds on the ResizeObserver api, which isn't supported in all browsers yet (and is only supported in very new versions of the popular browsers).
While we wait for a complete winit solution, I've added a `fit_canvas_to_parent` option to WindowDescriptor / Window, which when enabled will listen for window resizes and resize the Bevy canvas/window to fit its parent element. This enables users to scale bevy canvases using arbitrary CSS, by "inheriting" their parents' size. Note that the wrapper element _is_ required because winit overrides the canvas sizing with absolute values on each resize.
There is one limitation worth calling out here: while the majority of canvas resizes will be triggered by window resizes, modifying element layout at runtime (css animations, javascript-driven element changes, dev-tool-injected changes, etc) will not be detected here. I'm not aware of a good / efficient event-driven way to do this outside of the ResizeObserver api. In practice, window-resize-driven canvas resizing should cover the majority of use cases. Users that want to actively poll for element resizes can just do that (or we can build another feature and let people choose based on their specific needs).
I also took the chance to make a couple of minor tweaks:
* Made the `canvas` window setting available on all platforms. Users shouldn't need to deal with cargo feature selection to support web scenarios. We can just ignore the value on non-web platforms. I added documentation that explains this.
* Removed the redundant "initial create windows" handler. With the addition of the code in this pr, the code duplication was untenable.
This enables a number of patterns:
## Easy "fullscreen window" mode for the default canvas
The "parent element" defaults to the `<body>` element.
```rust
app
.insert_resource(WindowDescriptor {
fit_canvas_to_parent: true,
..default()
})
```
And CSS:
```css
html, body {
margin: 0;
height: 100%;
}
```
## Fit custom canvas to "wrapper" parent element
```rust
app
.insert_resource(WindowDescriptor {
fit_canvas_to_parent: true,
canvas: Some("#bevy".to_string()),
..default()
})
```
And the HTML:
```html
<div style="width: 50%; height: 100%">
<canvas id="bevy"></canvas>
</div>
```
2022-05-20 23:13:48 +00:00
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
mod web_resize;
|
2020-08-21 05:37:19 +00:00
|
|
|
mod winit_config;
|
2020-03-30 21:53:32 +00:00
|
|
|
mod winit_windows;
|
2021-01-01 21:31:22 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
use bevy_ecs::system::{SystemParam, SystemState};
|
|
|
|
use system::{changed_window, create_window, despawn_window};
|
|
|
|
|
2020-08-21 05:37:19 +00:00
|
|
|
pub use winit_config::*;
|
|
|
|
pub use winit_windows::*;
|
2020-03-28 00:43:03 +00:00
|
|
|
|
2022-03-01 19:33:56 +00:00
|
|
|
use bevy_app::{App, AppExit, CoreStage, Plugin};
|
2023-01-19 00:38:28 +00:00
|
|
|
use bevy_ecs::event::{Events, ManualEventReader};
|
2022-05-05 13:35:43 +00:00
|
|
|
use bevy_ecs::prelude::*;
|
2023-01-19 00:38:28 +00:00
|
|
|
use bevy_input::{
|
|
|
|
keyboard::KeyboardInput,
|
|
|
|
mouse::{MouseButtonInput, MouseMotion, MouseScrollUnit, MouseWheel},
|
|
|
|
touch::TouchInput,
|
2022-03-01 19:33:56 +00:00
|
|
|
};
|
2023-01-19 00:38:28 +00:00
|
|
|
use bevy_math::{ivec2, DVec2, Vec2};
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
use bevy_utils::{
|
2023-01-19 00:38:28 +00:00
|
|
|
tracing::{trace, warn},
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
Instant,
|
|
|
|
};
|
2020-04-19 19:13:04 +00:00
|
|
|
use bevy_window::{
|
2023-01-31 01:47:00 +00:00
|
|
|
exit_on_all_closed, CursorEntered, CursorLeft, CursorMoved, FileDragAndDrop, Ime,
|
|
|
|
ModifiesWindows, ReceivedCharacter, RequestRedraw, Window, WindowBackendScaleFactorChanged,
|
2023-01-29 20:27:29 +00:00
|
|
|
WindowCloseRequested, WindowCreated, WindowFocused, WindowMoved, WindowResized,
|
|
|
|
WindowScaleFactorChanged,
|
2020-04-19 19:13:04 +00:00
|
|
|
};
|
2022-05-05 13:35:43 +00:00
|
|
|
|
2020-03-28 00:43:03 +00:00
|
|
|
use winit::{
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
event::{self, DeviceEvent, Event, StartCause, WindowEvent},
|
2020-03-30 21:53:32 +00:00
|
|
|
event_loop::{ControlFlow, EventLoop, EventLoopWindowTarget},
|
2020-03-28 00:43:03 +00:00
|
|
|
};
|
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
use crate::system::WinitWindowInfo;
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
use crate::web_resize::{CanvasParentResizeEventChannel, CanvasParentResizePlugin};
|
|
|
|
|
2020-03-29 07:53:47 +00:00
|
|
|
#[derive(Default)]
|
|
|
|
pub struct WinitPlugin;
|
|
|
|
|
2020-08-08 03:22:17 +00:00
|
|
|
impl Plugin for WinitPlugin {
|
2021-07-27 20:21:06 +00:00
|
|
|
fn build(&self, app: &mut App) {
|
2023-01-19 00:38:28 +00:00
|
|
|
let event_loop = EventLoop::new();
|
|
|
|
app.insert_non_send_resource(event_loop);
|
|
|
|
|
2022-02-24 01:40:02 +00:00
|
|
|
app.init_non_send_resource::<WinitWindows>()
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
.init_resource::<WinitSettings>()
|
2020-10-15 18:42:19 +00:00
|
|
|
.set_runner(winit_runner)
|
2023-01-19 00:38:28 +00:00
|
|
|
.add_system_set_to_stage(
|
|
|
|
CoreStage::PostUpdate,
|
|
|
|
SystemSet::new()
|
|
|
|
.label(ModifiesWindows)
|
2023-01-31 01:47:00 +00:00
|
|
|
// exit_on_all_closed only uses the query to determine if the query is empty,
|
|
|
|
// and so doesn't care about ordering relative to changed_window
|
|
|
|
.with_system(changed_window.ambiguous_with(exit_on_all_closed))
|
|
|
|
// Update the state of the window before attempting to despawn to ensure consistent event ordering
|
|
|
|
.with_system(despawn_window.after(changed_window)),
|
2023-01-19 00:38:28 +00:00
|
|
|
);
|
2022-09-06 14:45:44 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
app.add_plugin(CanvasParentResizePlugin);
|
2022-07-04 13:04:14 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
#[cfg(not(target_arch = "wasm32"))]
|
|
|
|
let mut create_window_system_state: SystemState<(
|
|
|
|
Commands,
|
|
|
|
NonSendMut<EventLoop<()>>,
|
|
|
|
Query<(Entity, &mut Window)>,
|
|
|
|
EventWriter<WindowCreated>,
|
|
|
|
NonSendMut<WinitWindows>,
|
|
|
|
)> = SystemState::from_world(&mut app.world);
|
2022-07-04 13:04:14 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
let mut create_window_system_state: SystemState<(
|
|
|
|
Commands,
|
|
|
|
NonSendMut<EventLoop<()>>,
|
|
|
|
Query<(Entity, &mut Window)>,
|
|
|
|
EventWriter<WindowCreated>,
|
|
|
|
NonSendMut<WinitWindows>,
|
|
|
|
ResMut<CanvasParentResizeEventChannel>,
|
|
|
|
)> = SystemState::from_world(&mut app.world);
|
2021-05-14 20:37:32 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
// And for ios and macos, we should not create window early, all ui related code should be executed inside
|
|
|
|
// UIApplicationMain/NSApplicationMain.
|
|
|
|
#[cfg(not(any(target_os = "android", target_os = "ios", target_os = "macos")))]
|
|
|
|
{
|
|
|
|
#[cfg(not(target_arch = "wasm32"))]
|
|
|
|
let (commands, event_loop, mut new_windows, event_writer, winit_windows) =
|
|
|
|
create_window_system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
let (commands, event_loop, mut new_windows, event_writer, winit_windows, event_channel) =
|
|
|
|
create_window_system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
// Here we need to create a winit-window and give it a WindowHandle which the renderer can use.
|
|
|
|
// It needs to be spawned before the start of the startup-stage, so we cannot use a regular system.
|
|
|
|
// Instead we need to create the window and spawn it using direct world access
|
|
|
|
create_window(
|
|
|
|
commands,
|
|
|
|
&event_loop,
|
|
|
|
new_windows.iter_mut(),
|
|
|
|
event_writer,
|
|
|
|
winit_windows,
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
event_channel,
|
|
|
|
);
|
2022-05-05 13:35:43 +00:00
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
|
|
|
create_window_system_state.apply(&mut app.world);
|
2022-05-05 13:35:43 +00:00
|
|
|
}
|
2020-03-29 07:53:47 +00:00
|
|
|
}
|
|
|
|
|
2020-08-21 05:37:19 +00:00
|
|
|
fn run<F>(event_loop: EventLoop<()>, event_handler: F) -> !
|
|
|
|
where
|
|
|
|
F: 'static + FnMut(Event<'_, ()>, &EventLoopWindowTarget<()>, &mut ControlFlow),
|
|
|
|
{
|
|
|
|
event_loop.run(event_handler)
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: It may be worth moving this cfg into a procedural macro so that it can be referenced by
|
|
|
|
// a single name instead of being copied around.
|
|
|
|
// https://gist.github.com/jakerr/231dee4a138f7a5f25148ea8f39b382e seems to work.
|
|
|
|
#[cfg(any(
|
|
|
|
target_os = "windows",
|
|
|
|
target_os = "macos",
|
|
|
|
target_os = "linux",
|
|
|
|
target_os = "dragonfly",
|
|
|
|
target_os = "freebsd",
|
|
|
|
target_os = "netbsd",
|
|
|
|
target_os = "openbsd"
|
|
|
|
))]
|
|
|
|
fn run_return<F>(event_loop: &mut EventLoop<()>, event_handler: F)
|
|
|
|
where
|
|
|
|
F: FnMut(Event<'_, ()>, &EventLoopWindowTarget<()>, &mut ControlFlow),
|
|
|
|
{
|
2020-12-13 19:27:54 +00:00
|
|
|
use winit::platform::run_return::EventLoopExtRunReturn;
|
2022-02-08 04:14:33 +00:00
|
|
|
event_loop.run_return(event_handler);
|
2020-08-21 05:37:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(not(any(
|
|
|
|
target_os = "windows",
|
|
|
|
target_os = "macos",
|
|
|
|
target_os = "linux",
|
|
|
|
target_os = "dragonfly",
|
|
|
|
target_os = "freebsd",
|
|
|
|
target_os = "netbsd",
|
|
|
|
target_os = "openbsd"
|
|
|
|
)))]
|
2020-09-16 20:40:32 +00:00
|
|
|
fn run_return<F>(_event_loop: &mut EventLoop<()>, _event_handler: F)
|
2020-08-21 05:37:19 +00:00
|
|
|
where
|
|
|
|
F: FnMut(Event<'_, ()>, &EventLoopWindowTarget<()>, &mut ControlFlow),
|
|
|
|
{
|
|
|
|
panic!("Run return is not supported on this platform!")
|
|
|
|
}
|
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
#[derive(SystemParam)]
|
|
|
|
struct WindowEvents<'w> {
|
|
|
|
window_resized: EventWriter<'w, WindowResized>,
|
|
|
|
window_close_requested: EventWriter<'w, WindowCloseRequested>,
|
|
|
|
window_scale_factor_changed: EventWriter<'w, WindowScaleFactorChanged>,
|
|
|
|
window_backend_scale_factor_changed: EventWriter<'w, WindowBackendScaleFactorChanged>,
|
|
|
|
window_focused: EventWriter<'w, WindowFocused>,
|
|
|
|
window_moved: EventWriter<'w, WindowMoved>,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(SystemParam)]
|
|
|
|
struct InputEvents<'w> {
|
|
|
|
keyboard_input: EventWriter<'w, KeyboardInput>,
|
|
|
|
character_input: EventWriter<'w, ReceivedCharacter>,
|
|
|
|
mouse_button_input: EventWriter<'w, MouseButtonInput>,
|
|
|
|
mouse_wheel_input: EventWriter<'w, MouseWheel>,
|
|
|
|
touch_input: EventWriter<'w, TouchInput>,
|
2023-01-29 20:27:29 +00:00
|
|
|
ime_input: EventWriter<'w, Ime>,
|
2023-01-19 00:38:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(SystemParam)]
|
|
|
|
struct CursorEvents<'w> {
|
|
|
|
cursor_moved: EventWriter<'w, CursorMoved>,
|
|
|
|
cursor_entered: EventWriter<'w, CursorEntered>,
|
|
|
|
cursor_left: EventWriter<'w, CursorLeft>,
|
2020-12-24 18:43:30 +00:00
|
|
|
}
|
|
|
|
|
2021-10-29 00:46:18 +00:00
|
|
|
// #[cfg(any(
|
|
|
|
// target_os = "linux",
|
|
|
|
// target_os = "dragonfly",
|
|
|
|
// target_os = "freebsd",
|
|
|
|
// target_os = "netbsd",
|
|
|
|
// target_os = "openbsd"
|
|
|
|
// ))]
|
|
|
|
// pub fn winit_runner_any_thread(app: App) {
|
|
|
|
// winit_runner_with(app, EventLoop::new_any_thread());
|
|
|
|
// }
|
2020-12-24 18:43:30 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
/// Stores state that must persist between frames.
|
|
|
|
struct WinitPersistentState {
|
|
|
|
/// Tracks whether or not the application is active or suspended.
|
|
|
|
active: bool,
|
|
|
|
/// Tracks whether or not an event has occurred this frame that would trigger an update in low
|
|
|
|
/// power mode. Should be reset at the end of every frame.
|
|
|
|
low_power_event: bool,
|
|
|
|
/// Tracks whether the event loop was started this frame because of a redraw request.
|
|
|
|
redraw_request_sent: bool,
|
|
|
|
/// Tracks if the event loop was started this frame because of a `WaitUntil` timeout.
|
|
|
|
timeout_reached: bool,
|
|
|
|
last_update: Instant,
|
|
|
|
}
|
|
|
|
impl Default for WinitPersistentState {
|
|
|
|
fn default() -> Self {
|
|
|
|
Self {
|
|
|
|
active: true,
|
|
|
|
low_power_event: false,
|
|
|
|
redraw_request_sent: false,
|
|
|
|
timeout_reached: false,
|
|
|
|
last_update: Instant::now(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
pub fn winit_runner(mut app: App) {
|
|
|
|
// We remove this so that we have ownership over it.
|
2022-02-08 23:04:19 +00:00
|
|
|
let mut event_loop = app
|
|
|
|
.world
|
|
|
|
.remove_non_send_resource::<EventLoop<()>>()
|
|
|
|
.unwrap();
|
2023-01-19 00:38:28 +00:00
|
|
|
|
2021-01-19 06:23:30 +00:00
|
|
|
let mut app_exit_event_reader = ManualEventReader::<AppExit>::default();
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
let mut redraw_event_reader = ManualEventReader::<RequestRedraw>::default();
|
|
|
|
let mut winit_state = WinitPersistentState::default();
|
2022-02-08 23:04:19 +00:00
|
|
|
app.world
|
|
|
|
.insert_non_send_resource(event_loop.create_proxy());
|
2020-03-28 00:43:03 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
let return_from_run = app.world.resource::<WinitSettings>().return_from_run;
|
Optionally resize Window canvas element to fit parent element (#4726)
Currently Bevy's web canvases are "fixed size". They are manually set to specific dimensions. This might be fine for some games and website layouts, but for sites with flexible layouts, or games that want to "fill" the browser window, Bevy doesn't provide the tools needed to make this easy out of the box.
There are third party plugins like [bevy-web-resizer](https://github.com/frewsxcv/bevy-web-resizer/) that listen for window resizes, take the new dimensions, and resize the winit window accordingly. However this only covers a subset of cases and this is common enough functionality that it should be baked into Bevy.
A significant motivating use case here is the [Bevy WASM Examples page](https://bevyengine.org/examples/). This scales the canvas to fit smaller windows (such as mobile). But this approach both breaks winit's mouse events and removes pixel-perfect rendering (which means we might be rendering too many or too few pixels). https://github.com/bevyengine/bevy-website/issues/371
In an ideal world, winit would support this behavior out of the box. But unfortunately that seems blocked for now: https://github.com/rust-windowing/winit/pull/2074. And it builds on the ResizeObserver api, which isn't supported in all browsers yet (and is only supported in very new versions of the popular browsers).
While we wait for a complete winit solution, I've added a `fit_canvas_to_parent` option to WindowDescriptor / Window, which when enabled will listen for window resizes and resize the Bevy canvas/window to fit its parent element. This enables users to scale bevy canvases using arbitrary CSS, by "inheriting" their parents' size. Note that the wrapper element _is_ required because winit overrides the canvas sizing with absolute values on each resize.
There is one limitation worth calling out here: while the majority of canvas resizes will be triggered by window resizes, modifying element layout at runtime (css animations, javascript-driven element changes, dev-tool-injected changes, etc) will not be detected here. I'm not aware of a good / efficient event-driven way to do this outside of the ResizeObserver api. In practice, window-resize-driven canvas resizing should cover the majority of use cases. Users that want to actively poll for element resizes can just do that (or we can build another feature and let people choose based on their specific needs).
I also took the chance to make a couple of minor tweaks:
* Made the `canvas` window setting available on all platforms. Users shouldn't need to deal with cargo feature selection to support web scenarios. We can just ignore the value on non-web platforms. I added documentation that explains this.
* Removed the redundant "initial create windows" handler. With the addition of the code in this pr, the code duplication was untenable.
This enables a number of patterns:
## Easy "fullscreen window" mode for the default canvas
The "parent element" defaults to the `<body>` element.
```rust
app
.insert_resource(WindowDescriptor {
fit_canvas_to_parent: true,
..default()
})
```
And CSS:
```css
html, body {
margin: 0;
height: 100%;
}
```
## Fit custom canvas to "wrapper" parent element
```rust
app
.insert_resource(WindowDescriptor {
fit_canvas_to_parent: true,
canvas: Some("#bevy".to_string()),
..default()
})
```
And the HTML:
```html
<div style="width: 50%; height: 100%">
<canvas id="bevy"></canvas>
</div>
```
2022-05-20 23:13:48 +00:00
|
|
|
|
2020-11-13 01:23:57 +00:00
|
|
|
trace!("Entering winit event loop");
|
2020-08-21 05:37:19 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut focused_window_state: SystemState<(Res<WinitSettings>, Query<&Window>)> =
|
|
|
|
SystemState::from_world(&mut app.world);
|
|
|
|
|
|
|
|
#[cfg(not(target_arch = "wasm32"))]
|
|
|
|
let mut create_window_system_state: SystemState<(
|
|
|
|
Commands,
|
|
|
|
Query<(Entity, &mut Window), Added<Window>>,
|
|
|
|
EventWriter<WindowCreated>,
|
|
|
|
NonSendMut<WinitWindows>,
|
|
|
|
)> = SystemState::from_world(&mut app.world);
|
|
|
|
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
let mut create_window_system_state: SystemState<(
|
|
|
|
Commands,
|
|
|
|
Query<(Entity, &mut Window), Added<Window>>,
|
|
|
|
EventWriter<WindowCreated>,
|
|
|
|
NonSendMut<WinitWindows>,
|
|
|
|
ResMut<CanvasParentResizeEventChannel>,
|
|
|
|
)> = SystemState::from_world(&mut app.world);
|
|
|
|
|
2020-08-21 05:37:19 +00:00
|
|
|
let event_handler = move |event: Event<()>,
|
|
|
|
event_loop: &EventLoopWindowTarget<()>,
|
|
|
|
control_flow: &mut ControlFlow| {
|
2022-11-14 23:08:31 +00:00
|
|
|
#[cfg(feature = "trace")]
|
|
|
|
let _span = bevy_utils::tracing::info_span!("winit event_handler").entered();
|
2023-01-19 00:38:28 +00:00
|
|
|
|
|
|
|
if let Some(app_exit_events) = app.world.get_resource::<Events<AppExit>>() {
|
|
|
|
if app_exit_event_reader.iter(app_exit_events).last().is_some() {
|
|
|
|
*control_flow = ControlFlow::Exit;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
#[cfg(not(target_arch = "wasm32"))]
|
|
|
|
let (commands, mut new_windows, created_window_writer, winit_windows) =
|
|
|
|
create_window_system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
let (
|
|
|
|
commands,
|
|
|
|
mut new_windows,
|
|
|
|
created_window_writer,
|
|
|
|
winit_windows,
|
|
|
|
canvas_parent_resize_channel,
|
|
|
|
) = create_window_system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
// Responsible for creating new windows
|
|
|
|
create_window(
|
|
|
|
commands,
|
|
|
|
event_loop,
|
|
|
|
new_windows.iter_mut(),
|
|
|
|
created_window_writer,
|
|
|
|
winit_windows,
|
|
|
|
#[cfg(target_arch = "wasm32")]
|
|
|
|
canvas_parent_resize_channel,
|
|
|
|
);
|
|
|
|
|
|
|
|
create_window_system_state.apply(&mut app.world);
|
|
|
|
}
|
|
|
|
|
2020-03-30 18:52:33 +00:00
|
|
|
match event {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
event::Event::NewEvents(start) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
let (winit_config, window_focused_query) = focused_window_state.get(&app.world);
|
|
|
|
|
|
|
|
let app_focused = window_focused_query.iter().any(|window| window.focused);
|
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
// Check if either the `WaitUntil` timeout was triggered by winit, or that same
|
|
|
|
// amount of time has elapsed since the last app update. This manual check is needed
|
|
|
|
// because we don't know if the criteria for an app update were met until the end of
|
|
|
|
// the frame.
|
|
|
|
let auto_timeout_reached = matches!(start, StartCause::ResumeTimeReached { .. });
|
|
|
|
let now = Instant::now();
|
2023-01-19 00:38:28 +00:00
|
|
|
let manual_timeout_reached = match winit_config.update_mode(app_focused) {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
UpdateMode::Continuous => false,
|
|
|
|
UpdateMode::Reactive { max_wait }
|
|
|
|
| UpdateMode::ReactiveLowPower { max_wait } => {
|
|
|
|
now.duration_since(winit_state.last_update) >= *max_wait
|
|
|
|
}
|
|
|
|
};
|
|
|
|
// The low_power_event state and timeout must be reset at the start of every frame.
|
|
|
|
winit_state.low_power_event = false;
|
|
|
|
winit_state.timeout_reached = auto_timeout_reached || manual_timeout_reached;
|
|
|
|
}
|
2020-04-19 19:13:04 +00:00
|
|
|
event::Event::WindowEvent {
|
|
|
|
event,
|
|
|
|
window_id: winit_window_id,
|
|
|
|
..
|
2020-12-27 19:24:31 +00:00
|
|
|
} => {
|
2023-01-19 00:38:28 +00:00
|
|
|
// Fetch and prepare details from the world
|
|
|
|
let mut system_state: SystemState<(
|
|
|
|
NonSend<WinitWindows>,
|
|
|
|
Query<(&mut Window, &mut WinitWindowInfo)>,
|
|
|
|
WindowEvents,
|
|
|
|
InputEvents,
|
|
|
|
CursorEvents,
|
|
|
|
EventWriter<FileDragAndDrop>,
|
|
|
|
)> = SystemState::new(&mut app.world);
|
|
|
|
let (
|
|
|
|
winit_windows,
|
|
|
|
mut window_query,
|
|
|
|
mut window_events,
|
|
|
|
mut input_events,
|
|
|
|
mut cursor_events,
|
|
|
|
mut file_drag_and_drop_events,
|
|
|
|
) = system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
// Entity of this window
|
|
|
|
let window_entity =
|
|
|
|
if let Some(entity) = winit_windows.get_window_entity(winit_window_id) {
|
|
|
|
entity
|
2020-12-27 19:24:31 +00:00
|
|
|
} else {
|
|
|
|
warn!(
|
2023-01-19 00:38:28 +00:00
|
|
|
"Skipped event {:?} for unknown winit Window Id {:?}",
|
|
|
|
event, winit_window_id
|
|
|
|
);
|
|
|
|
return;
|
|
|
|
};
|
|
|
|
|
|
|
|
let (mut window, mut info) =
|
|
|
|
if let Ok((window, info)) = window_query.get_mut(window_entity) {
|
|
|
|
(window, info)
|
|
|
|
} else {
|
|
|
|
warn!(
|
|
|
|
"Window {:?} is missing `Window` component, skipping event {:?}",
|
|
|
|
window_entity, event
|
2020-12-27 19:24:31 +00:00
|
|
|
);
|
|
|
|
return;
|
|
|
|
};
|
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
winit_state.low_power_event = true;
|
2020-12-27 19:24:31 +00:00
|
|
|
|
|
|
|
match event {
|
|
|
|
WindowEvent::Resized(size) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
window
|
|
|
|
.resolution
|
|
|
|
.set_physical_resolution(size.width, size.height);
|
|
|
|
info.last_winit_size = size;
|
|
|
|
|
|
|
|
window_events.window_resized.send(WindowResized {
|
|
|
|
window: window_entity,
|
2020-12-27 19:24:31 +00:00
|
|
|
width: window.width(),
|
|
|
|
height: window.height(),
|
|
|
|
});
|
|
|
|
}
|
|
|
|
WindowEvent::CloseRequested => {
|
2023-01-19 00:38:28 +00:00
|
|
|
window_events
|
|
|
|
.window_close_requested
|
|
|
|
.send(WindowCloseRequested {
|
|
|
|
window: window_entity,
|
|
|
|
});
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::KeyboardInput { ref input, .. } => {
|
2023-01-19 00:38:28 +00:00
|
|
|
input_events
|
|
|
|
.keyboard_input
|
|
|
|
.send(converters::convert_keyboard_input(input));
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::CursorMoved { position, .. } => {
|
2023-01-19 00:38:28 +00:00
|
|
|
let physical_position = DVec2::new(
|
|
|
|
position.x,
|
|
|
|
// Flip the coordinate space from winit's context to our context.
|
|
|
|
window.resolution.physical_height() as f64 - position.y,
|
|
|
|
);
|
2022-11-10 20:10:51 +00:00
|
|
|
|
2023-01-21 00:01:28 +00:00
|
|
|
// bypassing change detection to not trigger feedback loop with system `changed_window`
|
|
|
|
// this system change the cursor position in winit
|
|
|
|
window
|
|
|
|
.bypass_change_detection()
|
|
|
|
.set_physical_cursor_position(Some(physical_position));
|
2020-12-03 19:30:27 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
cursor_events.cursor_moved.send(CursorMoved {
|
|
|
|
window: window_entity,
|
|
|
|
position: (physical_position / window.resolution.scale_factor())
|
|
|
|
.as_vec2(),
|
2020-08-21 00:04:01 +00:00
|
|
|
});
|
|
|
|
}
|
2020-12-27 19:24:31 +00:00
|
|
|
WindowEvent::CursorEntered { .. } => {
|
2023-01-19 00:38:28 +00:00
|
|
|
cursor_events.cursor_entered.send(CursorEntered {
|
|
|
|
window: window_entity,
|
|
|
|
});
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::CursorLeft { .. } => {
|
2023-01-19 00:38:28 +00:00
|
|
|
// Component
|
|
|
|
if let Ok((mut window, _)) = window_query.get_mut(window_entity) {
|
2023-01-21 00:01:28 +00:00
|
|
|
// bypassing change detection to not trigger feedback loop with system `changed_window`
|
|
|
|
// this system change the cursor position in winit
|
|
|
|
window
|
|
|
|
.bypass_change_detection()
|
|
|
|
.set_physical_cursor_position(None);
|
2023-01-19 00:38:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
cursor_events.cursor_left.send(CursorLeft {
|
|
|
|
window: window_entity,
|
|
|
|
});
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::MouseInput { state, button, .. } => {
|
2023-01-19 00:38:28 +00:00
|
|
|
input_events.mouse_button_input.send(MouseButtonInput {
|
2020-12-27 19:24:31 +00:00
|
|
|
button: converters::convert_mouse_button(button),
|
|
|
|
state: converters::convert_element_state(state),
|
2020-08-21 00:04:01 +00:00
|
|
|
});
|
|
|
|
}
|
2020-12-27 19:24:31 +00:00
|
|
|
WindowEvent::MouseWheel { delta, .. } => match delta {
|
|
|
|
event::MouseScrollDelta::LineDelta(x, y) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
input_events.mouse_wheel_input.send(MouseWheel {
|
2020-12-27 19:24:31 +00:00
|
|
|
unit: MouseScrollUnit::Line,
|
|
|
|
x,
|
|
|
|
y,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
event::MouseScrollDelta::PixelDelta(p) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
input_events.mouse_wheel_input.send(MouseWheel {
|
2020-12-27 19:24:31 +00:00
|
|
|
unit: MouseScrollUnit::Pixel,
|
|
|
|
x: p.x as f32,
|
|
|
|
y: p.y as f32,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
},
|
|
|
|
WindowEvent::Touch(touch) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut location =
|
|
|
|
touch.location.to_logical(window.resolution.scale_factor());
|
|
|
|
|
|
|
|
// On a mobile window, the start is from the top while on PC/Linux/OSX from
|
|
|
|
// bottom
|
|
|
|
if cfg!(target_os = "android") || cfg!(target_os = "ios") {
|
|
|
|
location.y = window.height() as f64 - location.y;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Event
|
|
|
|
input_events
|
|
|
|
.touch_input
|
|
|
|
.send(converters::convert_touch_input(touch, location));
|
2020-11-03 19:32:48 +00:00
|
|
|
}
|
2020-12-27 19:24:31 +00:00
|
|
|
WindowEvent::ReceivedCharacter(c) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
input_events.character_input.send(ReceivedCharacter {
|
|
|
|
window: window_entity,
|
2020-12-27 19:24:31 +00:00
|
|
|
char: c,
|
2022-02-13 22:33:55 +00:00
|
|
|
});
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::ScaleFactorChanged {
|
|
|
|
scale_factor,
|
|
|
|
new_inner_size,
|
|
|
|
} => {
|
2023-01-19 00:38:28 +00:00
|
|
|
window_events.window_backend_scale_factor_changed.send(
|
|
|
|
WindowBackendScaleFactorChanged {
|
|
|
|
window: window_entity,
|
|
|
|
scale_factor,
|
|
|
|
},
|
|
|
|
);
|
|
|
|
|
|
|
|
let prior_factor = window.resolution.scale_factor();
|
|
|
|
window.resolution.set_scale_factor(scale_factor);
|
|
|
|
let new_factor = window.resolution.scale_factor();
|
|
|
|
|
|
|
|
if let Some(forced_factor) = window.resolution.scale_factor_override() {
|
2021-09-10 18:46:16 +00:00
|
|
|
// If there is a scale factor override, then force that to be used
|
|
|
|
// Otherwise, use the OS suggested size
|
|
|
|
// We have already told the OS about our resize constraints, so
|
|
|
|
// the new_inner_size should take those into account
|
2023-01-19 00:38:28 +00:00
|
|
|
*new_inner_size =
|
|
|
|
winit::dpi::LogicalSize::new(window.width(), window.height())
|
|
|
|
.to_physical::<u32>(forced_factor);
|
|
|
|
// TODO: Should this not trigger a WindowsScaleFactorChanged?
|
2021-09-10 18:46:16 +00:00
|
|
|
} else if approx::relative_ne!(new_factor, prior_factor) {
|
2023-01-19 00:38:28 +00:00
|
|
|
// Trigger a change event if they are approximately different
|
|
|
|
window_events.window_scale_factor_changed.send(
|
|
|
|
WindowScaleFactorChanged {
|
|
|
|
window: window_entity,
|
|
|
|
scale_factor,
|
|
|
|
},
|
|
|
|
);
|
2020-12-28 20:26:50 +00:00
|
|
|
}
|
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
let new_logical_width = (new_inner_size.width as f64 / new_factor) as f32;
|
|
|
|
let new_logical_height = (new_inner_size.height as f64 / new_factor) as f32;
|
|
|
|
if approx::relative_ne!(window.width(), new_logical_width)
|
|
|
|
|| approx::relative_ne!(window.height(), new_logical_height)
|
2020-12-28 20:26:50 +00:00
|
|
|
{
|
2023-01-19 00:38:28 +00:00
|
|
|
window_events.window_resized.send(WindowResized {
|
|
|
|
window: window_entity,
|
|
|
|
width: new_logical_width,
|
|
|
|
height: new_logical_height,
|
2020-12-28 20:26:50 +00:00
|
|
|
});
|
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
window
|
|
|
|
.resolution
|
|
|
|
.set_physical_resolution(new_inner_size.width, new_inner_size.height);
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
|
|
|
WindowEvent::Focused(focused) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
// Component
|
|
|
|
window.focused = focused;
|
|
|
|
|
|
|
|
window_events.window_focused.send(WindowFocused {
|
|
|
|
window: window_entity,
|
2020-12-18 21:08:26 +00:00
|
|
|
focused,
|
2020-12-27 19:24:31 +00:00
|
|
|
});
|
2020-12-18 21:08:26 +00:00
|
|
|
}
|
2021-01-01 21:31:22 +00:00
|
|
|
WindowEvent::DroppedFile(path_buf) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
file_drag_and_drop_events.send(FileDragAndDrop::DroppedFile {
|
|
|
|
window: window_entity,
|
2021-01-01 21:31:22 +00:00
|
|
|
path_buf,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
WindowEvent::HoveredFile(path_buf) => {
|
2023-01-19 00:38:28 +00:00
|
|
|
file_drag_and_drop_events.send(FileDragAndDrop::HoveredFile {
|
|
|
|
window: window_entity,
|
2021-01-01 21:31:22 +00:00
|
|
|
path_buf,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
WindowEvent::HoveredFileCancelled => {
|
2023-01-19 00:38:28 +00:00
|
|
|
file_drag_and_drop_events.send(FileDragAndDrop::HoveredFileCancelled {
|
|
|
|
window: window_entity,
|
|
|
|
});
|
2021-01-01 21:31:22 +00:00
|
|
|
}
|
2021-01-25 04:06:06 +00:00
|
|
|
WindowEvent::Moved(position) => {
|
|
|
|
let position = ivec2(position.x, position.y);
|
2023-01-19 00:38:28 +00:00
|
|
|
|
|
|
|
window.position.set(position);
|
|
|
|
|
|
|
|
window_events.window_moved.send(WindowMoved {
|
|
|
|
entity: window_entity,
|
2021-01-25 04:06:06 +00:00
|
|
|
position,
|
|
|
|
});
|
|
|
|
}
|
2023-01-29 20:27:29 +00:00
|
|
|
WindowEvent::Ime(event) => match event {
|
|
|
|
event::Ime::Preedit(value, cursor) => {
|
|
|
|
input_events.ime_input.send(Ime::Preedit {
|
|
|
|
window: window_entity,
|
|
|
|
value,
|
|
|
|
cursor,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
event::Ime::Commit(value) => input_events.ime_input.send(Ime::Commit {
|
|
|
|
window: window_entity,
|
|
|
|
value,
|
|
|
|
}),
|
|
|
|
event::Ime::Enabled => input_events.ime_input.send(Ime::Enabled {
|
|
|
|
window: window_entity,
|
|
|
|
}),
|
|
|
|
event::Ime::Disabled => input_events.ime_input.send(Ime::Disabled {
|
|
|
|
window: window_entity,
|
|
|
|
}),
|
|
|
|
},
|
2020-12-27 19:24:31 +00:00
|
|
|
_ => {}
|
2020-12-07 21:24:25 +00:00
|
|
|
}
|
2020-12-27 19:24:31 +00:00
|
|
|
}
|
2020-12-07 19:57:15 +00:00
|
|
|
event::Event::DeviceEvent {
|
2022-09-06 14:45:44 +00:00
|
|
|
event: DeviceEvent::MouseMotion { delta: (x, y) },
|
2020-12-07 19:57:15 +00:00
|
|
|
..
|
|
|
|
} => {
|
2023-01-19 00:38:28 +00:00
|
|
|
let mut system_state: SystemState<EventWriter<MouseMotion>> =
|
|
|
|
SystemState::new(&mut app.world);
|
|
|
|
let mut mouse_motion = system_state.get_mut(&mut app.world);
|
|
|
|
|
|
|
|
mouse_motion.send(MouseMotion {
|
|
|
|
delta: Vec2::new(x as f32, y as f32),
|
2020-12-07 19:57:15 +00:00
|
|
|
});
|
2020-08-16 07:30:04 +00:00
|
|
|
}
|
2021-07-16 00:50:39 +00:00
|
|
|
event::Event::Suspended => {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
winit_state.active = false;
|
2021-07-16 00:50:39 +00:00
|
|
|
}
|
|
|
|
event::Event::Resumed => {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
winit_state.active = true;
|
2021-07-16 00:50:39 +00:00
|
|
|
}
|
2020-03-30 18:52:33 +00:00
|
|
|
event::Event::MainEventsCleared => {
|
2023-01-19 00:38:28 +00:00
|
|
|
let (winit_config, window_focused_query) = focused_window_state.get(&app.world);
|
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
let update = if winit_state.active {
|
2023-01-19 00:38:28 +00:00
|
|
|
// True if _any_ windows are currently being focused
|
|
|
|
let app_focused = window_focused_query.iter().any(|window| window.focused);
|
|
|
|
match winit_config.update_mode(app_focused) {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
UpdateMode::Continuous | UpdateMode::Reactive { .. } => true,
|
|
|
|
UpdateMode::ReactiveLowPower { .. } => {
|
|
|
|
winit_state.low_power_event
|
|
|
|
|| winit_state.redraw_request_sent
|
|
|
|
|| winit_state.timeout_reached
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
false
|
|
|
|
};
|
2023-01-19 00:38:28 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
if update {
|
|
|
|
winit_state.last_update = Instant::now();
|
2021-07-16 00:50:39 +00:00
|
|
|
app.update();
|
|
|
|
}
|
2020-03-28 00:43:03 +00:00
|
|
|
}
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
Event::RedrawEventsCleared => {
|
|
|
|
{
|
2023-01-19 00:38:28 +00:00
|
|
|
// Fetch from world
|
|
|
|
let (winit_config, window_focused_query) = focused_window_state.get(&app.world);
|
|
|
|
|
|
|
|
// True if _any_ windows are currently being focused
|
|
|
|
let app_focused = window_focused_query.iter().any(|window| window.focused);
|
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
let now = Instant::now();
|
|
|
|
use UpdateMode::*;
|
2023-01-19 00:38:28 +00:00
|
|
|
*control_flow = match winit_config.update_mode(app_focused) {
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
Continuous => ControlFlow::Poll,
|
|
|
|
Reactive { max_wait } | ReactiveLowPower { max_wait } => {
|
2022-06-02 19:42:20 +00:00
|
|
|
if let Some(instant) = now.checked_add(*max_wait) {
|
|
|
|
ControlFlow::WaitUntil(instant)
|
|
|
|
} else {
|
|
|
|
ControlFlow::Wait
|
|
|
|
}
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
// This block needs to run after `app.update()` in `MainEventsCleared`. Otherwise,
|
|
|
|
// we won't be able to see redraw requests until the next event, defeating the
|
|
|
|
// purpose of a redraw request!
|
|
|
|
let mut redraw = false;
|
|
|
|
if let Some(app_redraw_events) = app.world.get_resource::<Events<RequestRedraw>>() {
|
|
|
|
if redraw_event_reader.iter(app_redraw_events).last().is_some() {
|
|
|
|
*control_flow = ControlFlow::Poll;
|
|
|
|
redraw = true;
|
|
|
|
}
|
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
winit_state.redraw_request_sent = redraw;
|
|
|
|
}
|
2023-01-19 00:38:28 +00:00
|
|
|
|
2020-03-30 18:52:33 +00:00
|
|
|
_ => (),
|
|
|
|
}
|
2020-08-21 05:37:19 +00:00
|
|
|
};
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
|
2023-01-19 00:38:28 +00:00
|
|
|
// If true, returns control from Winit back to the main Bevy loop
|
Reduce power usage with configurable event loop (#3974)
# Objective
- Reduce power usage for games when not focused.
- Reduce power usage to ~0 when a desktop application is minimized (opt-in).
- Reduce power usage when focused, only updating on a `winit` event, or the user sends a redraw request. (opt-in)
https://user-images.githubusercontent.com/2632925/156904387-ec47d7de-7f06-4c6f-8aaf-1e952c1153a2.mp4
Note resource usage in the Task Manager in the above video.
## Solution
- Added a type `UpdateMode` that allows users to specify how the winit event loop is updated, without exposing winit types.
- Added two fields to `WinitConfig`, both with the `UpdateMode` type. One configures how the application updates when focused, and the other configures how the application behaves when it is not focused. Users can modify this resource manually to set the type of event loop control flow they want.
- For convenience, two functions were added to `WinitConfig`, that provide reasonable presets: `game()` (default) and `desktop_app()`.
- The `game()` preset, which is used by default, is unchanged from current behavior with one exception: when the app is out of focus the app updates at a minimum of 10fps, or every time a winit event is received. This has a huge positive impact on power use and responsiveness on my machine, which will otherwise continue running the app at many hundreds of fps when out of focus or minimized.
- The `desktop_app()` preset is fully reactive, only updating when user input (winit event) is supplied or a `RedrawRequest` event is sent. When the app is out of focus, it only updates on `Window` events - i.e. any winit event that directly interacts with the window. What this means in practice is that the app uses *zero* resources when minimized or not interacted with, but still updates fluidly when the app is out of focus and the user mouses over the application.
- Added a `RedrawRequest` event so users can force an update even if there are no events. This is useful in an application when you want to, say, run an animation even when the user isn't providing input.
- Added an example `low_power` to demonstrate these changes
## Usage
Configuring the event loop:
```rs
use bevy::winit::{WinitConfig};
// ...
.insert_resource(WinitConfig::desktop_app()) // preset
// or
.insert_resource(WinitConfig::game()) // preset
// or
.insert_resource(WinitConfig{ .. }) // manual
```
Requesting a redraw:
```rs
use bevy::window::RequestRedraw;
// ...
fn request_redraw(mut event: EventWriter<RequestRedraw>) {
event.send(RequestRedraw);
}
```
## Other details
- Because we have a single event loop for multiple windows, every time I've mentioned "focused" above, I more precisely mean, "if at least one bevy window is focused".
- Due to a platform bug in winit (https://github.com/rust-windowing/winit/issues/1619), we can't simply use `Window::request_redraw()`. As a workaround, this PR will temporarily set the window mode to `Poll` when a redraw is requested. This is then reset to the user's `WinitConfig` setting on the next frame.
2022-03-07 23:32:05 +00:00
|
|
|
if return_from_run {
|
2020-08-21 05:37:19 +00:00
|
|
|
run_return(&mut event_loop, event_handler);
|
|
|
|
} else {
|
|
|
|
run(event_loop, event_handler);
|
|
|
|
}
|
2020-03-29 07:53:47 +00:00
|
|
|
}
|