Closed brettchalupa closed 1 month ago
@brettchalupa, Thanks! Yes, checked and this is also true for me on Intel I'll look into this
It seems that changin the config field blocking_event_loop
to true
for the macos fixes the problem. Maybe run
method of the NSApplication class was utilizing the same mecanism under the hood. Or maybe not. As for the dynamic quad
example the problem persists where the blocking...
config value is obviously not the solution.
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!
I look into this approach if my solution will not work
Now I'm trying to implement own nsview with opengl support as it was done in glfw
It uses flushBuffer
method that should use less cpu, because it syncs to screen refresh rate
https://developer.apple.com/documentation/appkit/nsopenglcontext/1436211-flushbuffer?language=objc
But I didn't spent much time during week
And somehow basic test with this approach redraws only background and not geometry, so I'm still debugging
https://github.com/birhburh/miniquad/tree/macos_prototype Everything should work now with opengl/metal backend: low cpu usage as before, even resize If you can, please test it on arm apple laptops ;-) Not making PR yet though Need to fix metal backend working with macroquad (again draws quarter of image) And also test blocking event loop now And do some cleanup
@birhburh I tested out your macos_prototype
branch on your fork on my M2 Pro chip, and when I run cargo run --release --example triangle
there's a segfault crash:
Let me know if there's more useful info to provide.
Edit: also seeing a segfault on the latest master
in miniquad with this PR merging https://github.com/not-fl3/miniquad/pull/475#issuecomment-2284181822 (commit: 30b4e17ece36d93988e65d8e57227c21f62b4002
)
@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
:tada:
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 https://github.com/not-fl3/macroquad/commit/93b8af24fd99d8a8f2cd4e2446260a43df36e1d6 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 bisect
on Miniquad, usingcargo run --release --example triangle
as my test for CPU usage. Some examples:cargo run --release --example triangle
cargo run --release --example triangle
Through the bisect, I landed on and confirmed that this commit https://github.com/not-fl3/miniquad/commit/833799ec32883cdd7465a5f8ddc80e2203dbcbc4 increases CPU load on MacOS by about 8x. First noticeable with the v0.4.4 release of Miniquad.
Repro steps
git checkout 833799ec32883cdd7465a5f8ddc80e2203dbcbc4^1
cargo run --release --example triangle
to see CPU performance baselinegit checkout 833799ec32883cdd7465a5f8ddc80e2203dbcbc4
cargo run --release --example triangle
to 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!