Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Heh, I installed this and immediately found out that "LegacyScreenSaver" has leaked 40 GB of memory.


are you on a work laptop? A lot of times they have screensavers for intel arch, and apple silicon might have something to do with this problem


No, it's my personal laptop and the screensaver is definitely native (ARM). It's probably just Apple being sloppy again.


40 GB is not simple sloppiness when it comes to a simple screensaver. I would encourage you to explore other solutions than to just blame it on some historical precedent you've experienced. However true it may be. It's just not likely given the criteria.


Apparently it is slopiness in the form of an undocumented API contract breakage.

https://github.com/lpar/RedPill/issues/8 (the screensaver I use)

https://www.jwz.org/blog/2023/10/xscreensaver-6-08-out-now/ (linked from there)

Maybe I should submit a PR with this workaround.


Yes I can confirm it's exactly that.

Basically Apple made a new "safe" API for screensavers (via .appex) but is only using it internally. 3rd party screensavers must still use the old unsafe API (that uses plugins, so unsafe code).

To bridge that gap, Apple made legacyScreenSaver, an .appex that loads the plugin code. It's a great concept in practice, but the implementation has been a mess since macOS 10.15 (Catalina...), breaking many things (multi monitor support was a big one, broken in many different ways over the years). Some Apple built in screensavers haven't been ported to the new API, so you may still have issues with legacyScreenSaver without that.

With macOS 14, Apple broke it again and indeed, legacyScreenSaver no longer tells the third party screensaver to quit! My rough guess is that this is linked to the way they implemented the transition with the new built in aerial videos they added that "slows" down on your desktop (on practice, it's not the screensaver that becomes the desktop, but 2 separate process/video players that gets synced up!).

Anyway, it's been a mess for third party developers for a while (I make one called Aerial). Our best workaround is to listen for a macOS event that tells us the screensaver will exit, and time our way to forcing an exit (literally, we call exit() which we shouldn't do, but that's the only workaround that works-ish). It works maybe 99% of the time. But sometimes legacyScreenSaver still craps out on its own.

Killing it manually will fix things (you will get a black screen + some CPU usage until you do, that can get bad depending on the screensaver) too.

I (and others) reported that bug multiple times but it's been 1 year+ and nothing. It's a mess.


Why use power and memory to run a screensaver when you can put the display to sleep?


Screensavers do seem like a relic from the CRT era, but there is probably a fraction of a second difference between waking a display and simply dismissing a screensaver, which I imagine matters to some people.


Ah in that case I apologize. Truly baffling situation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: