Third-party screensavers not quitting on Sonoma - any workarounds?

Question

Created Sep ’23

Replies 6

Boosts 3

Views 2.1k

Participants 5

I've run into a really weird bug with a macOS screen saver I've been developing using the ScreenSaver framework. It works fine on Ventura, but on Sonoma, when the user dismisses the screensaver, it continues to animate invisibly in the background using up CPU and GPU cycles. Even worse, when the user activates the screensaver a second time, yet another copy appears to be created, and so on. The call to stop animating is also never sent to the view, as far as I can tell.

I logged this as FB13041503 already, but I'm trying to come up with a workaround now, since this is still happening in the release version of macOS 14.0.

Any ideas how I can detect that the screensaver has been dismissed, so I can minimise my resource usage? I've even tried watching for things like NSWindowDidChangeOcclusionStateNotification but nothing seems to get called that I can use.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’23

It’s taken me a while, but I finally have the info I need to act here (-:

I logged this as FB13041503 already

Thanks for that.

Have you tried this on the latest macOS 14.1b2 seed (23B5056e)? I don’t have any solid evidence that it’s fixed there, but I just want to establish a new baseline.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

jamesthomson OP

Oct ’23

Yes, it's still happening on 14.1b1 and b2. Every time the screensaver is activated, I can see an additional thread being created in the legacyScreenSaver (Wallpaper) process. The closest I have to a workaround is to poll the view's window's windowLevel, which appears to change depending on whether the screensaver is currently active.

One thought I had was that there was some kind of retain cycle happening, and that's why my view isn't getting deallocated in this new screensaver process, but it doesn't seem to be the case at least when it's running within a regular app context.

Also, I do get the "startAnimating" calls, but never see any "stopAnimating" calls.

0

Answer 3

MadWizard OP

Dec ’23

This is REALLY annoying. Before Sonoma my MacBook usually kept cold to the touch. But nowdays often when I wonder why my keyboard is getting hot, it turns out there is at least one legacyScreenSaver process in the background, happily consuming about 20 % of the processing ressources – without any observable benefit. I am using the latest public version of Sonoma (14.1.2) and have to additional external displays, which amounts to 3 in total.

PLEASE FIX

0

Answer 4

pabugeater OP

Jan ’24

I see behavior as well. And FYI location services appears to be broken: no delegate methods are ever called, which grounds my saver completely.

0

Answer 5

XMI OP

Apr ’24

There are many bugs with third-party screensavers under Sonoma.

Here's a long thread that discusses a number of fixes: https://github.com/JohnCoates/Aerial/issues/1305

In particular, if your screensaver detects when it needs to exit, it can call exit(0) which seems to do the trick. Direct link: https://github.com/JohnCoates/Aerial/issues/1305#issuecomment-1680853387

1

Answer 6

DTS Engineer OP

Apple

Jul ’24

There are many bugs with third-party screensavers under Sonoma.

Yep )-:

If you care about screen savers then my advice is that you file an enhancement request for Apple to ship a new screen saver API based on app extensions. The legacy screen saver API relies on a complicated compatibility shim, and that’s a source of ongoing problems.

And hey, if we did an appex we could support Apple TV (-: [1]

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] No, that’s not a product announcement, it’s just my personal wish for a better future.

0