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.

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

maplibre-demo: High CPU and GPU usage on macOS while idle #187

Open
vollkorntomate opened this issue Oct 25, 2022 · 3 comments
Open

maplibre-demo: High CPU and GPU usage on macOS while idle #187

vollkorntomate opened this issue Oct 25, 2022 · 3 comments
Labels
bug Something isn't working

Comments

@vollkorntomate
Copy link

vollkorntomate commented Oct 25, 2022

The maplibre-demo binary has a quite high CPU and GPU usage when doing nothing. Activity monitor shows around 40% CPU usage and between 25-35% GPU usage while the app is in the foreground (and has focus) and no layers are being visibly rendered and the map is not interacted with. Roughly the same usage is reported while the app is in the background (window has no focus)

🤔 Expected Behavior

The CPU and GPU usage should be at a minimum, near 0%.

😯 Current Behavior

See above.

The latest commits (from Oct 23 and 24) seem to have improved the issue. Earlier, GPU usage was near 100% while in background. However, this improvement might also be due to the macOS Ventura update.

💁 Possible Solution

I was able to narrow down the source of the problem to apparently be inside maplibre-winit/src/winit/mod.rs:170 and the call to map_schedule::InteractiveMapSchedule::update_and_redraw(), since the RedrawRequested event fires multiple times per second and thus the map re-renders all the time, costing CPU and GPU resources.

A possible solution might be to only redraw the map if

  1. it has been moved or zoomed since the last redraw or
  2. loading the map hasn't finished and thus new objects need to be rendered

🌍 Your Environment

  • Desktop
    • macOS 13.0 (Ventura)
    • M1 Max, 24 GPU Cores
  • commit ec1ad07
  • built with cargo build -p maplibre-demo
  • run with ./target/debug/maplibre-demo headed
@vollkorntomate vollkorntomate added the bug Something isn't working label Oct 25, 2022
@maxammann
Copy link
Collaborator

Did you run your experiments in release mode?

I'm actually not entirely certain what to expect in terms of numbers. I think there are also multiple effects which play a role here:

  • maplibre-rs is in background and currently not visible

    In this case its the job of the OS to reduce the framerate. Browsers like Firefox do this sucessfully right now with maplibre-rs
    No animations are currently running in maplibre-rs. The map is not moved. Data is not updated. Window is not resized. -> We should limit the frame-rate to 0 FPS in this case. No need to redraw. We need an issue for that.

After all I think that maplibre-rs even when running with 60FPS it should not consume more than 5% of CPU if the map is not moved. We need to get a feeling first on how much "energy" a simple renderer should take (energy = CPU cycles/s and GPU usage).

So we need more numbers here before.

@vollkorntomate
Copy link
Author

vollkorntomate commented Oct 26, 2022

Did you run your experiments in release mode?

I actually ran them in debug mode. Just now I tried it again in release mode and it doesn't seem to make any difference, the numbers are the same.

No animations are currently running in maplibre-rs. The map is not moved. Data is not updated. Window is not resized. We should limit the frame-rate to 0 FPS in this case. No need to redraw. We need an issue for that.

Is this linked to an issue or somewhere from the roadmap?

@maxammann
Copy link
Collaborator

Is this linked to an issue or somewhere from the roadmap?

Not yet, but we probably could create an RFC which is called "energy saving", or just directly create an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants