Re: [historical] reasoning behind 88 colors

[G. Branden Robinson]

At 2020-03-19T04:58:16-0400, Thomas Dickey wrote:
> The size of the colormap is probably the main issue.
> The X server has a lookup table for colors which has limited size.

To expand on this a bit for Nick's benefit, the "Visual" used by the X
server for the display is the limiting factor.

Back in the day, say the mid-1990s, it wasn't uncommon to still be using
the occasional Sun-3 workstation or even a PC with video hardware that
only supported 8-bit color--in other words, 256 distinct colors on the
screen at the same time, at most[1].

When people were just running Athena and Motif apps of 1992 vintage, 256
colors seemed like enough for anyone.

Then the Web happened and everybody was running a browser and viewing
images[2].  And then you'd run into a problem.  Each time a color was
needed, in the "PsuedoColor Visual" used, it was allocated, and then
generally did not change for the lifetime of the X server, often a login
session.  This meant that if you viewed a photorealistic image, the
colors you got were on a first-come, first-served basis and depended on
the particulars of the image.  Then, later, when you launched other
apps, you might find that their colors were different from what you were
used to, because colormap entries had already been consumed, and you got
the "closest match", which might not be very close at all.

Even within a single application it could be a problem.  Imagine a
program like ImageMagick (which was around then and now).  View a jungle
scene in a Pseudocolor visual and it might look fine, but the next
image, launched from adifferent xterm, of desert terrain, might look
badly color-distorted.

Why did it work this way?  My understanding is that it had to do with
the limitations of the video hardware at the time.  The color signal was
usually analog (whether sent out to a CRT via a VGA connector or 5
cables with BNC connectors) which gave you a lot of flexibility,
color-wise.  You could show millions of colors, but you only had 1 byte
with which to index them.  Hence, the colormap.  More powerful video
hardware used more bits of color information per pixel, and the X server
provided other Visuals that could take advantage of them; one of them
was called "TrueColor".  With 15/16-bit and 24-bit color, you could
encode a color value more-or-less directly, and a DAC (digital-to-analog
converter) would convert it to chroma signals on the wire.  This is an
approximate description, and there is much complexity to analog color
encoding and signalling that is beginning to fade from experience and
memory nowadays.

You can read more about X11 Visuals here[3], which appears to be an HTML
version of the Xlib Programming Manual.

> I recall that running Netscape would cause the colormap to be mostly
> allocated for that application, making the colors unavailable to
> other applications.

Yes.  There was one other workaround; there was a way in the X protocol
to have a client (like xterm or Netscape or xmh) "install a private
colormap".  This meant that the client got its own 256-entry color map
index, which only applied when that client had the keyboard focus.  This
produced an interesting (or jarring) effect when you moved the pointer
between windows that had different private colormaps, or those that had
them and those that didn't.  You could even call it "trippy".  Some
people didn't like that, and telling xterm not to eat up so many
colormap entries was a compromise between telling it to run hog wild and
so it could render every color available in the hardware, and limiting
oneself to only 16.

I have to admit, I never personally knew of anyone who was particularly
animated about 88-color terminal windows.  People seemed to fall into
three camps:

1. "traditional xterm was black on white and that's all I'll ever need;"
2. "an appoximation of the EGA/VGA PC console is fine;"
3. "I run Gentoo and I want everything maxed out even if I won't use it"

Of course, camp #3 has described me best for many years in spite of my
Gentoo joke because I adopted video hardware with 24-bit color soon as I
could afford it.  Its resource cost in xterm is negligible these days.

Even 256 colors are not enough for cheeky modern xterm users.  They want
direct RGB color programming via terminal escapes so they can render
full-motion video in 24-bit color using ASCII art.  And thanks to
xterm extensions, they have them.  :D

Regards,
Branden

[1] Barring anorak tricks involving switching the colormap out partway
down the screen while the CRT beam was off and moving to the next
scanline.  The X server did not support this kind of tomfoolery and it
was not very portable, but you can find "demoscene" stuff from the
non-Unix world that exploited it.

[2] Also there were obnoxious people who'd seen the Commodore Amiga and
were wondering why their expensive Unix workstations couldn't "do that".

[3] https://tronche.com/gui/x/xlib/window/visual-types.html

signature.asc
Description: PGP signature