Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Switching desktops causes a spike in usage #8080

Closed
rendaoer opened this issue Mar 14, 2023 · 7 comments · Fixed by #7611 · May be fixed by #9034
Closed

Switching desktops causes a spike in usage #8080

rendaoer opened this issue Mar 14, 2023 · 7 comments · Fixed by #7611 · May be fixed by #9034
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times O-MacOS Specific to the MacOS (Apple) desktop operating system

Comments

@rendaoer
Copy link

Bevy version

v0.10.0

[Optional] Relevant system information

If you cannot get Bevy to build or run on your machine, please include:

  • the Rust version you're using (you can get this by running cargo --version)
    cargo 1.67.1 (8ecd4f20a 2023-01-10)
  • the operating system or browser used, including its version
    macOS Ventura 13.2.1

If your bug is rendering-related, copy the adapter info that appears when you run Bevy.

SystemInfo { os: "MacOS 13.2.1 ", kernel: "22.3.0", cpu: "Apple M1", core_count: "8", memory: "8.0 GiB" }

What you did

On macOS, I'm used to using multiple desktops for windows [main desktop, browser, VS Code], and when I run a bevy program, a window is created on the main desktop, which is all fine at that point. By the time I switch to another desktop, the footprint of this bevy program goes up a lot, causing my computer to start heating up. This problem has nothing to do with my code, it just needs to be run and it will do that.

Additional information

Other information that can be used to further reproduce or isolate the problem.
This commonly includes:

  • screenshots
    Normal: image

Switch desktop for a while and then come back: image
@rendaoer rendaoer added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Mar 14, 2023
@rendaoer
Copy link
Author

image

Switching desktops means this: image

@alice-i-cecile alice-i-cecile added O-MacOS Specific to the MacOS (Apple) desktop operating system C-Performance A change motivated by improving speed, memory usage or compile times A-Windowing Platform-agnostic interface layer to run your app in and removed S-Needs-Triage This issue needs to be labelled labels Mar 14, 2023
@alice-i-cecile
Copy link
Member

I bet that this is no longer being framerate throttled by vsync. Can you check how fast your main loop runs while your desktop is swapped? And try playing with https://docs.rs/bevy/latest/bevy/window/enum.PresentMode.html

@rendaoer
Copy link
Author

I bet that this is no longer being framerate throttled by vsync. Can you check how fast your main loop runs while your desktop is swapped? And try playing with https://docs.rs/bevy/latest/bevy/window/enum.PresentMode.html

print.log
Exactly as you would expect, the frame rate stays at 60 or below when on the main desktop, whether in foreground or background, but once you switch desktops, the frame rate slowly rises to 1200fps

@rendaoer
Copy link
Author

I bet that this is no longer being framerate throttled by vsync. Can you check how fast your main loop runs while your desktop is swapped? And try playing with https://docs.rs/bevy/latest/bevy/window/enum.PresentMode.html

No matter which PresentMode I use, the effect is the same, and Vsync fails when switching desktops

@alice-i-cecile
Copy link
Member

Well, that's very helpful to know. What happens if you use bevy_framepace to limit the frame rate?

@rendaoer
Copy link
Author

Well, that's very helpful to know. What happens if you use bevy_framepace to limit the frame rate?

bevy_framepace is effective in terms of limiting the frame rate, but it feels like it causes significant frame rate fluctuations and doesn't support [email protected]

@mockersf
Copy link
Member

this is the same as #5856

@mockersf mockersf mentioned this issue Jul 4, 2023
Closed
@B-head B-head mentioned this issue Jul 6, 2023
Draft
8 tasks
@maniwani maniwani mentioned this issue Jul 26, 2023
Merged
github-merge-queue bot pushed a commit that referenced this issue Aug 3, 2023
@maniwani
Change WinitPlugin defaults to limit game update rate when window i…
bbf1c23 
…s not visible (#7611)

Fixes #5856. Fixes #8080. Fixes #9040.

# Objective

We need to limit the update rate of games whose windows are not visible
(minimized or completely occluded). Compositors typically ignore the
VSync settings of windows that aren't visible. That, combined with the
lack of rendering work, results in a scenario where an app becomes
completely CPU-bound and starts updating without limit.

There are currently three update modes.
- `Continuous` updates an app as often as possible.
- `Reactive` updates when new window or device events have appeared, a
timer expires, or a redraw is requested.
- `ReactiveLowPower` is the same as `Reactive` except it ignores device
events (e.g. general mouse movement).

The problem is that the default "game" settings are set to `Contiuous`
even when no windows are visible.

### More Context

- libsdl-org/SDL#1871
- glfw/glfw#680
- godotengine/godot#19741
- godotengine/godot#64708

## Solution

Change the default "unfocused" `UpdateMode` for games to
`ReactiveLowPower` just like desktop apps. This way, even when the
window is occluded, the app still updates at a sensible rate or if
something about the window changes. I chose 20Hz arbitrarily.
@cart cart closed this as completed in #7611 Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times O-MacOS Specific to the MacOS (Apple) desktop operating system
Projects
None yet
Milestone
No milestone
3 participants
@alice-i-cecile @mockersf @rendaoer