You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
it has been moved or zoomed since the last redraw or
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
The text was updated successfully, but these errors were encountered:
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).
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?
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 tomap_schedule::InteractiveMapSchedule::update_and_redraw()
, since theRedrawRequested
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
🌍 Your Environment
ec1ad07
cargo build -p maplibre-demo
./target/debug/maplibre-demo headed
The text was updated successfully, but these errors were encountered: