XScreenSaver 5.00 alpha 4

I've packaged up another alpha release of the OSX port of xscreensaver. It's coming along... all of the existing savers now compile on OSX, and almost all of them work to at least some degree (though many still have problems). Please give it a try if you are feeling adventurous:

I've put up my current todo list, in case any of you would like to help out... There's work in there that can be done on either the X11 or Cocoa version.

Tags: , , , ,
Current Music: Pailhead -- Anthem ♬

10 Responses:

  1. alierak says:

    For coral, it looks like st->max_points is uninitialized, so probably ends up being zero and causing lots of flushes.

    • alierak says:

      looks like max_points=200 and delay=2000 make reasonable defaults on my machine.

      • jwz says:

        Yep, that looks like it, thanks! Also I had the delay and delay2 logic reversed from how they were historically.

  2. duskwuff says:

    ping is going to need to call out to a setuid binary, as loading a setuid saver bundle obviously doesn't make ScreenSaverEngine go setuid. I recommend writing a helper binary, or just abusing /sbin/ping.

    • duskwuff says:

      Also, GL savers do some seriously weird things in demo mode if you switch to another pref pane or otherwise hide the view. I have a 100% working port of noof, but not enough time to check what you're doing differently. If you're interested, the source is available.

    • jwz says:

      Just calling /sbin/ping would solve all kinds of problems, but it's not really practical when you want to ping a couple hundred hosts at a time. (Forking a couple hundred times being contraindicated.)

  3. taffer says:

    apple2-main.c, filptext.c, fontglide.c, phosphor.c, starwars.c should all include <unistd.h> for the read() prototype. xanalogtv.c should include it, too, for gethostname().

    grab-ximage.c should include <xlockmore.h> to get the glXMakeCurrent() proto.

  4. alierak says:

    For galaxy, significantly increasing delay (to 10000 or so) may silence the warnings without making it seem too slow.

  5. alierak says:

    For celtic, part of the problem is that its draw routine calls usleep repeatedly to "animate" the pattern, so it needs a little state machine work (patch). It also uses the blocking erase routines.

    The rest of the reported blocking time is accounted for by its requested delay of 5 seconds between calls to the draw routine. It looks like usleep_and_process_events is fully capable of breaking down the 5 second sleep into 1/10 second quanta, so it remains responsive, *but* check_timing isn't called in between quanta so it reports having blocked the entire time.

    • jwz says:

      Thanks for the patch! And good catch on the check_timing thing. Just moving that call in works.