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

Fix high CPU usage when window is occluded on macOS #1003

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Thomas-Vos
Copy link

@Thomas-Vos Thomas-Vos commented Dec 9, 2024

My app is used a lot in the background, and I noticed high CPU usage in the native macOS version. With this PR, CPU usage is reduced when window is invisible by disabling drawing. This was already implemented for the JVM, and that behaviour is now copied to native macOS. So the code is similar to JVM parts in:

The draw function is now suspend, which required moving some other functions around. I tried to keep the implementation similar to the JVM version.

Testing

Tested using ./gradlew runNative in samples/SkiaMultiplatformSample. Now the CPU usage is reduced a lot when moving another (non transparent) app over the window.

Old behaviour

Screen.Recording.2024-12-09.at.17.23.28.mov

New behaviour with 300ms timeout

See reduction in CPU usage when window is invisible

Screen.Recording.2024-12-09.at.17.26.17.mov

New behaviour without 300ms timeout

Screen.Recording.2024-12-11.at.23.27.20.mov


// When window is not visible - it doesn't make sense to redraw fast to avoid battery drain.
if (isWindowOccluded) {
withTimeoutOrNull(300) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied this 300 millisecond value from the JVM code to keep it consistent. However, I don't understand the reason for this delay, why not just suspend indefinitely (on native & jvm)? I can remove this timeout if needed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some testing it seems all works fine without the 300ms timeout. CPU usage is reduced even more, on both native and JVM. Added a screenrecording with results for native app in the PR. I could not find any specific reason this timeout was added in git blame, so I removed it. If there's something I am missing please let me know.

What still stands out to me is that CPU and memory usage are both much lower for native vs JVM on my M1 Max macbook, with the same FPS result (100fps, my refresh rate). This is the also the case for my own much heavier app.

@MatkovIvan MatkovIvan requested a review from igordmn December 9, 2024 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant