Dear Lazyweb, do X11 PseudoColor displays still exist in the real world? Does that even work on modern Linux GUI desktops?My guess is that even the bittiest bittybox 5v microcontroller from the last decade that is capable of running Unix has an HDMI output and a 24-bit-deep TrueColor frame buffer.
And therefore I no longer have to worry about breaking compatibility with, like, pre-ANSI SunOS 4 systems in current XScreenSaver releases.
Dissenting opinions?
It is definitely edge case territory now.
Speaking of old SunOS boxes and PseudoColor,
XScreenSaver on a sparc 5 many (MANY) years ago resulted in one of my all time favorite error messages:
bsod: Couldn't allocate color Blue.
It depends on the age of the bittybox, but many of the newer ones don't have hardware support for PseudoColor--there is no hardware lookup table to map 8-bit pixel values to colors. If the box is designed for video playback and GL games, there's zero customer demand for the feature, and lookup tables take up an expensive chunk of die area.
Some newer display controllers don't understand pixels smaller than 16 bits--they have to have their GPU render anything with smaller pixels onto a 16 bit surface for display. These systems can probably emulate PseudoColor with GL at display frame rates if they had to--but for that matter, so could you, if you wanted to get that 1990's palette-cycling feel.
I think you misunderstood what was asked.
The original question framed PseudoColor as some sort of fallback, the thing you used when you didn't have the luxury of TrueColor, or maybe you didn't have enough RAM/CPU/GPU to waste multiple bytes on each pixel. Now the wheel has turned: TrueColor is the fallback, and PseudoColor is the luxury extension. More than that, PseudoColor is retro now.
PseudoColor is as visually distinctive and historically relevant as any of the other technology-emulating hacks in xscreensaver. It's kind of odd that xscreensaver doesn't have any hacks that really celebrate the unique properties--and especially the artifacts--of PseudoColor.
If we have screensavers that emulate the video subsystem of an Apple ][ interacting with a cheap analog television, we should have screensavers that emulate the glitchy feel of a PseudoColor
Windows 3.1Motif X11 desktop with a bunch of GIF viewer windows open. Think of a strictly 2D photopile, but with frames that look like window decorations instead of Polaroids, and each new window causing all the existing windows to flash into extreme false-color, or slowly refresh their contents with a reserved 16-color palette. Throw in a few compiled-in screenshots of vintage 1990's applications or web sites between the photos for extra authenticity. I could look at that all day. Heck, I did look at that all day a decade or three ago.But to address the original question: for the love of God, run that new hack, and any other new hacks, on TrueColor visuals. Nobody runs their displays on PseudoColor any more.
I recently was running Satori screensaver on my Mac, simular to "Plasma," but based on the Berkeley screensaver version. It did what you described to the login screen photos. It was cool and retro and silly.
@ThatCKS has written some blog posts about X11 color systems and from what I remembered no real systems lack TrueColor support
I'm willing to accept that if my project involves running X11 on something so enchantingly primitive that it doesn't have 24-bit color, it doesn't get a pretty screensaver. I'll be happy with DPMS working.
Therefore, everybody else should be, too.
Ah, yes... I don't remember exactly which upgrade pushed me over the edge into having a truecolor display, but I certainly remember my display turning lurid colors every time my mouse escaped the confines of the XV window before that.
I've always had a certain appreciation for code-for-life development. I think it is really neat that I can take 'modern' code and run it -- albeit slowly -- on ancient hardware. It speaks so highly of the Unix Philosophy that that kind of thing still works.
But... I think -dsr- has it right: If I ever do want to run XScreensaver on a SPARCstation with 4MB that I found in a dumpster in the Nevada desert, I can always dig the older versions out of the archive.
I officially absolve you of maintaining pseudocolor support ... for what that's worth.
I've got a couple of old display hacks that try to use DirectColor first, then PseudoColor. I never got around to making them use TrueColor. Although I did get around to re-writing them in HTML5/JavaScript/Canvas.
Although xdpyinfo shows my X server has both TrueColor and DirectColor visuals available. Maybe my bug is something else.
Anyway, my problem is the opposite of yours. I have old code that needs colormaps and I want to get it going on modern displays. You have code that works on modern displays and are wondering if you should keep it going on old colormap-only displays. I say don't bother.
I don't think that there is any reasonably modern hardware still using 8bpp/PseudoColor.
Also, my experiment a while ago was that modern XScreenSaver on old hardware is not really a viable proposition. Of course, that was rather extreme (old hardware and old operating system), however, the hardware itself is a limiting factor in more than one case (16MB of RAM and 25MHz CPU were somewhat.. suboptimal)
That said, it was pleasant to encounter this:
But for that, one could use older versions of XScreenSaver on older hardware (emulated, perhaps)
Any machine that can run fireworkx or xanalogtv can also do colormap rotation in swirl on a TrueColor visual.
Also I kind of agree with this experimental observation:
I remember monochrome noseguy! noseguy -mono doesn't seem to do the same thing, alas.
FYI, Here's another port of XScreenSaver (5.15, from 2011) to VMS.
You will break xscreensaver on Richard Stallman's laptop. Not good!
Never underestimate the value of deleting lines of code.
K3n.
From the person who still signs their posts.
As recently as 3 years ago I saw a bunch of Solaris machines running xscreensaver in DoD land. Part of the reason why they're still around is because they're really hard to replace, so that also means they're not going to be updating xscreensaver. You can probably generalize this and consider that anything with PseudoColor framebuffers still has them because they're impossible to update. I say get rid of the code if it makes your life easier.
but if you did find someone/machine who required pseudocolor, odds are the monitor would benefit from having a screensaver... that's a zen koan if there ever was one.
My cgfourteen says no.