MacOS CPU usage increased by 8x in v0.4.4 #470
Comments
brettchalupa
changed the title
|
@brettchalupa, Thanks! |
|
It seems that changin the config field |
|
Another guess that appeared while searching for a similar even_loop is potentially unlimited fps for the application which leeds to many useless iterations. |
|
@VanjaRo, thanks for the link! |
|
https://github.com/birhburh/miniquad/tree/macos_prototype |
- Reverted macos.rs to this implementation: not-fl3#443 (it's probably better compare changes with this PR than with latest commit to understand what was added additionally) - Now using own NSView with NSOpenGLContext instead of NSOpenGLView - For metal backend using redraw instead setNeedsDisplay, because somehow it reduces cpu usage (Cannot find info about enabling vsync like this in MTKView docs) - Fixed freezing on resize by drawing in draw_rect that called during "live resize"™. I don't like this approach, but it blocks main event loop while resizing, so it will not be some kind of concurency of opengl stuff i think - Reducing CPU usage when window is occluded - Added comments to hacky places, there are lots of them imo Fixes: - not-fl3#455 - not-fl3#470
- Reverted macos.rs to this implementation: #443 (it's probably better compare changes with this PR than with latest commit to understand what was added additionally) - Now using own NSView with NSOpenGLContext instead of NSOpenGLView - For metal backend using redraw instead setNeedsDisplay, because somehow it reduces cpu usage (Cannot find info about enabling vsync like this in MTKView docs) - Fixed freezing on resize by drawing in draw_rect that called during "live resize"™. I don't like this approach, but it blocks main event loop while resizing, so it will not be some kind of concurency of opengl stuff i think - Reducing CPU usage when window is occluded - Added comments to hacky places, there are lots of them imo Fixes: - #455 - #470
|
@birhburh I tested out your Translated Report from crashLet me know if there's more useful info to provide. Edit: also seeing a segfault on the latest |
|
@birhburh given your PRs have addressed things, is this good to close or is there more to be done here? Awesome work! |
|
@brettchalupa, thanks, i think it can be closed |
|
🎉 Great job @birhburh ! |
I noticed running a simple Macroquad example on MacOS 14.5 with an Apple M2 Pro chip was using a high amount of CPU. I checked out some previous versions of Macroquad and saw the performance was much better in older versions. Using
git bisect, I landed on not-fl3/macroquad@93b8af2 being the introduction of the high CPU usage, which contains a patch level upgrade for miniquad from 0.4.2 to 0.4.3 (which was yanked) and macroquad_macro from 0.1.7 to 0.1.8.So I ran a
git bisecton Miniquad, usingcargo run --release --example triangleas my test for CPU usage. Some examples:cargo run --release --example trianglecargo run --release --example triangleThrough the bisect, I landed on and confirmed that this commit 833799e increases CPU load on MacOS by about 8x. First noticeable with the v0.4.4 release of Miniquad.
Repro steps
git checkout 833799ec32883cdd7465a5f8ddc80e2203dbcbc4^1cargo run --release --example triangleto see CPU performance baselinegit checkout 833799ec32883cdd7465a5f8ddc80e2203dbcbc4cargo run --release --example triangleto see CPU performance degradeAdditional info
Happy to help test or debug, especially if access to MacOS is limited. @birhburh pinging you here too since you authored the commit. Let me know if I can be supportive in any way. Thanks!
The text was updated successfully, but these errors were encountered: