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

Prevent display sleep while game is running on macOS #1602

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dpogue
Copy link
Member

@dpogue dpogue commented Jul 8, 2024

Closes #1600

@dpogue dpogue requested a review from colincornaby July 8, 2024 18:45
@colincornaby
Copy link
Contributor

Was NSProcessInfo beginActivityWithOptions:reason: considered as an alternative?
https://developer.apple.com/documentation/foundation/nsprocessinfo/1415995-beginactivitywithoptions

Implementing beginActivityWithOptions:reason: has been on my list of things to do because I also feel like the app is less responsive when it's not in the foreground, which may reflect something like not passing a NSActivityUserInitiated or NSActivityBackground flag.

@dpogue
Copy link
Member Author

dpogue commented Jul 8, 2024

Was NSProcessInfo beginActivityWithOptions:reason: considered as an alternative?

I did not know that existed... all my investigation led to the IOKit API, which is also what's used internally by the caffeinate command-line tool.

One advantage of the IOKit code (besides it being C API and not ObjC 😛) is that it works back to OS X 10.5, whereas the NSProcessInfo code looks to be 10.7 and up only.

Do you know if there's an actual difference in implementation between the two, or does NSProcessInfo just call out to IOKit?

@colincornaby
Copy link
Contributor

beginActivity: seems to require 10.9 - which would be even higher. But - beginActivity also controls our QoS level in the operating system, which the IOKit call does not do. The reason I've been suspicious we might need this call is that our login window will not appear until the app is brought to the foreground - which could imply our run loop is getting squashed.

Application/backgrounding QoS was not introduced until later. Very possibly that release was 10.9. So the IOKit call would not cover that.

It's a bit of a mess, but:

  • We should probably make the AppKit call in 10.9 and later because that would preserve our background QoS.
  • Before that, we could make IOKit calls.

FWIW - I'd prefer if there was a compile path that did not include IOKit at all for later builds. It's not critical - but IOKit has bit by bit been getting deprecated or restricted. So it would be preferable if the modern builds didn't link IOKit just to reduce risk. Could just be that I'm overly cautious on IOKit use - but again, been seeing a lot of IOKit API getting deprecated.

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.

[macOS] Uru should (optionally) hold a wakelock assertion
2 participants