I'm still curious to hear from someone who has tried to run this on 10.4 PPC.
Let me know how it works...
XScreenSaver 5.10 out now
XScreenSaver 5.10 is out now. I think I have fixed the color and crashing problems on MacOS 10.6.
Tags: computers, firstperson, linux, mac, xscreensaver
Current Music: Kap Bambino -- Dead Lazers ♬
19 Responses:
> I'm still curious to hear from someone who has tried to run this on 10.4 PPC.
I was going to get back to you on that, except it turns out my old laptop is running 10.3. Did you know your home page is completely unusable in Safari 1.3? I'm sure that stings.
I know I have a 10.4 disk somewhere...
Colors in loaded .jpgs on ripples, zoom, and glslideshow look fine. PPC, 10.4.11.
It is also slow like a dog on my 1 GHz G4 imac, but that is not surprising.
Works fine so far on my G4 1.5ghz powerbook running 10.4.11
Pointing any of the image-related savers to a directory containing 5000+ images (in sub-directories), all in the 6+ "megapixel" range, is somewhat guaranteed to crater the machine for the next twenty minutes. Carousel, for example, will sit on "Loading Images...", cause the fans to spin up, etc. While this is happening no mouse or keyboard activity interrupts.
What it's doing is pretty straightforward -- it's just listing the directory and cacheing the result for 3 hours -- and hasn't changed. Try doing it by hand verbosely:
~/Library/Screen\ Savers/Carousel.saver/Contents/Resources/xscreensaver-getimage-file -vv ~/Pictures/YOUR_PICTURES_DIR
Yep. That's the cratering.
FWIW the manual run tells me that there are 9275 files in the cache. Each of the XScreenSaver modules has its own pref for what directory to look in for images (but they all share the same cache file), and selecting a saver from the "Preview" list in System Prefs causes the exisitng cache file to be thrown away and a new one built IF the image dir value is different.
I would be really spiffy if the cache lifetime could be set outside of the script itself, and it would be spiffy if there were a single spot that one could use to set the image dir for all savers. I suspect that there's a way to twiddle ~/.xscreensaver to make this happen.
But why is it taking so long? Because on my machine, with 30k+ images in the directory, it only takes a few seconds on the first run, and is instantaneous on subsequent runs in the same dir (after deleting the cache file).
The MacOS saver framework doesn't allow you to share preferences between screen savers. They each get their own plist file. That's how it's done.
I wish I knew why it was taking so long. Doing something as simple as this:
find ~/Pictures/Pics/Processed/ -name "*jpg" > /tmp/cache
takes well less than a second to process and happily finds 9243 images. I can find no good reason for why the perl script craters so badly. I don't see obvious CPU use, nor obvious memory problems. The machine (a year-old MacBook Pro) just slows to a crawl, the fans start blowing, and the hard drive thrashes.
When I ran the command you mentioned by hand the run was (usually) nearly instantaneous. Sometimes it cratered though:
xscreensaver-getimage-file: - found file /Users/.../DSC_1857.jpg
xscreensaver-getimage-file: - found file /Users/.../DSC_1858.jpg
xscreensaver-getimage-file: f=9275; d=577; s=1962; skip=2614+1386=4000.
xscreensaver-getimage-file: cached 9275 files
^CSegmentation fault
I had let it sit thrashing for over ten minutes before I ^Cd it.
(Paths shortened to make your window Not All Wide)
Well, I was gonna say "try adding -type f to find to make sure it stats all the files" but looking at the perl code, it's pretty smart about only statting once it needs to know if it's dealing with a directory, which is exactly what find does.
Segmentation faults in Perl are pretty damned far from being something I can do anything about.
Did it sit there for 10 min silently with -vv? Because that would be weird. Try it under truss maybe?
Welp ... truss for OSX seems to be eluding me. I found a dtruss that seems, under the covers, to be using DTrace, won't accept the -o switch that truss and strace like, and basically makes me angry. No joy there.
I notice that ~/Library/Logs/DiagnosticReports/ has many crash reports for perl. As you said - not much you can do if this is perl being stupid.
On the off chance the perl crash IS useful to you, the important bit looks like:
This also seems to be happening AFTER the cache file has been created. I can tickle the bad behavior at will be removing
, then running the manual creation process. If I then let it spin until crash OR ^C out of it
exists and appears to be a complete listing of what's supposed to exist. Subsequent runs of the create thinger then work more-or-less as expected:
(Paths once again shortened).
I've also noticed that Finder sluggishly tells me that I loose around 1.3G of my free HD space while the thrashing is happening, but when I finally manage to break out of the badness the missing space is returned to me.
My best (and not very good) guess right now is that this has something to do with releasing the lock that is being created.
I should also mention, though I suspect it is not relevant, that this machine is running a release slightly newer than 10.6. Unfortunately I don't have a vanilla 10.6 install handy with which to poke.
(Sorry for the multiple re-posts. The PRE lines were way too wide and had to be fixed.)
Changing
my $use_spotlight_p = 0;
to
my $use_spotlight_p = 1;
makes the pain go away.
You will have entirely other pain, like, "why are most of my images never being found".
That will make me sad.
Damn. I thought I was onto a solution.
Found the bug. Sort of.
It's in the sort().
Commenting out
@all_files = sort(@all_files);
makes the pain go away.
This seems to be a bug in the perl 5.10.0 in /usr/bin/perl:
# /usr/bin/perl -v
This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
Changing the #! line of the script to point at the perl installed by MacPorts makes the sort() badness go away:
# /opt/local/bin/perl -v
This is perl, v5.8.9 built for darwin-2level
I'll file a bug with Apple.
Well. One can't expect new technology like sorting to be completely worked out yet.
I wonder if this somehow has something to do with why makedepend sometimes never terminates. Though that doesn't seem to run perl.
A b00g is filed.
Incidentally it seems as though perl 5.8.9 and 5.10.0 are present in /usr/bin. I was able to work around this problem by:
sudo rm -rf /usr/bin/perl
sudo ln -s /usr/bin/perl5.8.9 /usr/bin/perl
I'm getting lots of crashing from these on 10.5.8 on Intel FWIW. I can paste in the crash reports if that would help.
Sure. I don't need the whole logs, just the first few lines of the backtrace of the thread that crashed.
Not sure if this is the necessary bit:
Application Specific Information:
|ScreenSaver|running|XMatrix
Thread 0 Crashed:
0 libSystem.B.dylib 0x971e3e42 __kill + 10
1 libSystem.B.dylib 0x9725623a raise + 26
2 libSystem.B.dylib 0x97262679 abort + 73
3 org.jwz.xscreensaver.CubicGrid 0x18549ab2 switch_to_resource + 449
4 org.jwz.xscreensaver.CubicGrid 0x18549be7 bind_switch_to_preferences + 31
5 org.jwz.xscreensaver.CubicGrid 0x1854a441 make_checkbox + 790
6 org.jwz.xscreensaver.CubicGrid 0x1854cd88 traverse_children + 965
7 org.jwz.xscreensaver.CubicGrid 0x1854e30b -[XScreenSaverConfigSheet initWithXMLFile:options:controller:] + 702
8 org.jwz.xscreensaver.CubicGrid 0x18550a13 -[XScreenSaverView configureSheet] + 308