XScreenSaver 5.09 out now

XScreenSaver 5.09 is out now! In addition to the appearance of a few new savers, this version works on Snow Leopard (as well as 10.4).

It has a few bugs, but since the previous version didn't run at all on 10.6, I'll call this the "better than nothing" release.

Some things I could use help with:

  1. There were some new color-endian issues with 10.6. I have tested it on a 10.5.8 PPC Mac and on a 10.6 Intel Mac. I would like to know if images are displaying properly (in, for example, the Ripples screen saver, when loading photos from disk) on 1) 10.4 Intel Macs, 2) 10.4 PPC Macs, and 3) 10.5 Intel Macs.
  2. Somehow the colors got screwed up in xmatrix on both 10.6 Intel and 10.5 PPC. It makes no sense to me that the colors are screwed up there but nowhere else. I'm lost in a twisty maze of endiannesses, all alike.   Update: I've fixed this, it will be in the next release.

  3. When running the savers under SaverTester or System Preferences on 10.6 (but not 10.5), I get frequent crashes at startup inside NSLayoutManager, as I mentioned earlier. I assume it is a memory corruption bug somewhere, but I can't find it.

  4. Someone needs to fix the configure.in file for autoconf 2.64. I can't make any sense of this bullshit change they've made: Expanded-Before-Required.html. I have no stomach for this, so until someone sends me a patch, I guess xscreensaver will require autoconf 2.63 or earlier.

  5. osxgrabscreen.m is using "deprecated functions" like CGDisplayAddressForPosition(), and that code was flaky to begin with. If someone would like to write me some "modern", non-deprecated code that grabs an image of the desktop and returns it as an array of RGB data, I would be most appreciative. This, apparently, is rocket science.   Update: Fixed this too, though the fix is 10.5-specific, so it will remain flaky on 10.4.

  6. Something has gone catastropically wrong with makedepend on 10.6. It takes like 15 minutes to process even a single one of the xscreensaver Makefiles. It's crazy. This is not an xscreensaver problem per se, but if you know a fix, I'd like to hear it.

Let me know how it works!

Tags: , , , , ,

32 Responses:

  1. mapzter says:

    Ripples works properly for me on a 10.5.8 Intel Mac.

  2. I was testing out the BSOD screen saver in 10.6 because when I upgraded, Snow Leopard told me my old BSOD screen saver wouldn't work anymore. With the new update, the screen saver opens in system preferences but quite a few of the death screens cause the screen saver to crash. Here are the death screens that made my computer crash:
    Windows 2000
    NVida (Has Crashed)
    Sad Mac (Discoloration and quits on exit)
    MacOS X (Has Crashed and doesn't retrieve a desktop image to use)
    Linux fsck
    Linux hppa

    The rest of the screen savers work with out catastrophic failures. So thats the info I've got on the BSOD screen saver. I've been using this screen saver for a few years now, so I just want to say thanks for still bothering to update a project this old. I thought I was going to need to get a new screen saver. Thanks.

  3. primaleph says:

    Working great for me so far.

    Also, for anyone else like me who's come to like having the Really Slick Screensavers package installed alongside XScreensaver on Linux, most of those savers have also been updated for OS X. They can be found at http://www.reallyslick.com/downloads.html ... all of the ones on Stephanie Sudre's page are updated, and most on Nick Zitzmann's page are as well. (Nice to have Lattice and Helios back.)

    • jwz says:

      Man, when those first came out I (obviously) wanted to incorporate them into the xscreensaver collection, and modify them take advantage of the shared framework my savers use for window management, options processing, etc. But, that would have meant mixing my X11-licensed code (with a "documentation" clause) with his GPL-licensed code, which you can't legally do. There have been so many hands in xscreensaver that it's impossible for me to adjust the license, and the author (Terry Welsh), who had the ability to re-license or dual-license his code, refused to, solely because he believed anything but GPL was "insufficiently free". Which means "insufficiently restrictive".

      So, that's lame.

      • primaleph says:

        They are indeed awesome.

        Since you like them so much, despite the licensing issues, did you consider linking to them on your download page? Or even repackaging them under the appropriate license to download along with XScreensaver (as a separate package)? More convenient, even if they aren't able to use your framework...

  4. berry_k says:

    I installed them on my 10.5.8 Intel Macbook and tried a random half dozen; all seemed to work fine. Now I'm ready for Snow Leopard! Thanks.

  5. lionsphil says:

    Intel Mac, OS 10.4.11. Maze (yay) preview, options, and test work. Ripples seems to have correct colours. GLSlideshow likewise.

    Have yet to notice anything broken.

  6. mayoff says:

    Regarding #5 (osxgrabscreen.m): Are you aware of /usr/sbin/screencapture? It has a man page.

    • jwz says:

      Yes, but it can only write to a file (or to the clipboard, which would rudely overwrite whatever else the user left there) so that doesn't really help.

      • mayoff says:

        The function you are looking for is CGWindowListCreateImage. This call will give you a CGImageRef for all windows across all screens:

        CGImageRef image = CGWindowListCreateImage(CGRectInfinite, kCGWindowListOptionAll, kCGNullWindowID, kCGWindowImageDefault);

        This example program will create /tmp/mygrab.png containing the screen image:

        #import <Cocoa/Cocoa.h>

        int main (int argc, const char * argv[]) {
        NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

        CGImageRef image = CGWindowListCreateImage(CGRectInfinite, kCGWindowListOptionAll, kCGNullWindowID, kCGWindowImageDefault);

        CFURLRef url = CFURLCreateWithFileSystemPath(NULL, CFSTR("/tmp/mygrab.png"), kCFURLPOSIXPathStyle, false);
        CGImageDestinationRef destination = CGImageDestinationCreateWithURL(url, kUTTypePNG, 1, NULL);
        CGImageDestinationAddImage(destination, image, NULL);
        [pool drain];
        return 0;

        You would probably use something like CGContextDrawImage instead of wanting to write it to a file.

        • jwz says:

          The good news: that works great, and is very simpe, thanks...

          The bad news: it only works in 10.5 or later.

          Which of course I only noticed after sinking a bunch of work into it. Dammit.

          • primaleph says:

            Would it be helpful if I let you know which screensavers crash on my Macbook with Snow Leopard?

            • jwz says:

              Only if they are crashing in ways that do not seem to be the (presumed) memory corruption that tends to manifest in NSLayoutManager.

              • primaleph says:

                What sort of messages should I look for in the bug screen to tell me whether or not that's the case? (Not a programmer here, but would like to help with bug reporting if I can.)

                • jwz says:

                  If the crash log says NSLayoutManager, it's not helpful.

                  If the crash is easily reproducible every time (like, 10x in a row, or it's clearly tied to a particular setting) then it might be one I can do something about. Otherwise, until I make this NSLayoutManager thing go away, it's hard to tell what's what.

  7. luserspaz says:

    And people wonder why Mozilla still requires autoconf 2.13. Why do purveyors of software tools insist on making non-backwards-compatible changes with no real gain for their users?

  8. rnp says:

    I had problems with makedepend getting insanely slow when it was searching for a header file that was referenced but not in makedepend's include path.

    • strspn says:

      Ah, hm. Programs that try too hard to track shit down for you: mixed feelings. Just hope they don't look to far into /dev.

  9. wfaulk says:

    Bumps consistently crashes on my (Intel) MBP3,1 running 10.6. The only errors I see are here. Despite the namespace clash, Abstractile never crashes. I guess it always picks that one.

    • wfaulk says:

      Whoops. Found the rest of the logs.

      • jwz says:

        I think I fixed that one:

        --- jwxyz.m 4 Sep 2009 06:44:39 -0000 1.58
        +++ jwxyz.m 5 Sep 2009 20:22:01 -0000 1.59
        @@ -1631,2 +1631,3 @@
        depth = d->pixmap.depth;
        + alpha_first_p = 1; // we created it with kCGImageAlphaNoneSkipFirst.
        ibpp = CGBitmapContextGetBitsPerPixel (d->cgc);
    • wfaulk says:


      The crash in XSetFont() feels familiar to the warning I get from FontGlide: "Can't exec "appres": No such file or directory at ..." and then a bunch of "Use of uninitialized value ..."s. I can do a trace to get the full warnings if you need more info for that one, but I'd guess that it all just has to do with appres not being found in the environment FontGlide gets run under. (I don't use the default shell, BTW, if that's relevant. I have no idea where that environment comes from.)

      • jwz says:

        The appres thing is because on OSX putenv() does not copy its arg, so you can't ever free it. In ScreenSaverView.m.

    • wfaulk says:

      The first time I ran XAnalogTV I got an insane amount (completely filled the 4000-line buffer) of this:

      9/7/09 10:08:11 PM	[0x0-0x9e09e].com.apple.systempreferences[2281]	objc[2281]: **resurrected** object 0x200b45280 of class NSCFArray being sent message 'containerSize'
      9/7/09 10:08:11 PM [0x0-0x9e09e].com.apple.systempreferences[2281] objc[2281]: **resurrected** object 0x200b45280 of class NSCFArray being sent message 'objectAtIndex:'
      9/7/09 10:08:11 PM [0x0-0x9e09e].com.apple.systempreferences[2281] objc[2281]: **resurrected** object 0x200b45280 of class NSCFArray being sent message 'containerSize'
      9/7/09 10:08:11 PM [0x0-0x9e09e].com.apple.systempreferences[2281] objc[2281]: **resurrected** object 0x7fff5fbfd9c0 of class nil being sent message '
      9/7/09 10:08:11 PM [0x0-0x9e09e].com.apple.systempreferences[2281] '
      9/7/09 10:08:11 PM [0x0-0x9e09e].com.apple.systempreferences[2281] *** process 2281 exceeded 500 log message per second limit - remaining messages this second discarded ***
      9/7/09 10:08:12 PM com.apple.launchd.peruser.501[129] ([0x0-0x9e09e].com.apple.systempreferences[2281]) Exited: Terminated

      The last line only happened once and the next-to-last line only happened once per second, obviously. The objects always seemed to be the same.

      I can't reproduce it, though. Now it just seems to die in validate_pixel() like Bumps.

      Feel free to tell me if these reports are useless. (Not that I think you're inclined to wait for permission.)