🚀 go-pugleaf

In article 3200@peking.gdwb.oz.au, csb@gdwb.oz.au (Craig Bishop) writes:
>Has anyone got a solution for this problem.
>
>Is it NeWS grabbing the colors or is it jet's fault.

It's NeWS.

>After running jet on a OW3 setup there are only about 40 colors
>of a 256 color palette left.

How many are left depends on whether you specify a cubesize when
starting openwindows.


This is an unavoidable consequence of attempting to reconcile the
NeWS and X11 color models.  X11 has a model where the application
is aware of the colormap and allocates colors into it, then refers
to them by index.  This is one reason why some X applications will
run in 8bit PsuedoColor framebuffers, but die on a 24bit TrueColor
display.  NeWS/PostScript has an abstract color model.  Colors are
specified as rgb (or hsb) triples and are not resolved into a colormap
index until it is actually time to render.  This makes NeWS/PostScript
programs highly independent of the underlying hardware.

There are two ways to resolve an abstract color to a colormap index
(on PsuedoColor displays or equivalent.)  One way is to choose the
closest availiable color, the other is to dither using availiable
colors.  On monochrome displays, NeWS dithers.  It will also dither
when using imagecanvas (or imagemaskcanvas) when the destination
is `shallower' than the source (i.e. source is 24bits, destination
is 8bits.)  However, most often it uses a closest-match lookup.

There are two potential problems with a simple closest-match algorithmn.
The first is linear search time.  The second is that if the colormap
is writeable, the closest-match may change over time.  (This may not
sound too bad, but there are some very odd consequences.  For example,
damage repair after changing the colormap may cause your drawing to
change color along the edges of the damage path.)  The problem with
dithering is that it is slower and fine lines (e.g. button borders)
look fuzzy when dithered.

To solve the closest-match problems, the X/NeWS server allows NeWS to
allocate a color `cube' (actually a rectangular solid with separate
gray ramp.)  The cube simply splits each axis of the rgb colorspace
into even chunks for fast lookup.  In addition, there is a separate
section which provides extra gray values not occurring in the main
cube.  (The default cube is 5x5x5, the large cube is 5x9x5.  I don't
recall how many extra grays there are in the standard cubes.  Since
I normally dither raster images to my background using NeWS, I've
been using a 6x13x3+18 cube.  Check out the NeWS 3.0 Programmer's
Guide, Appendix C - Colormaps and Colorcubes for more details.)

Since the cube is layed out in a regular pattern, and each axis is
divided evenly, quantizing an abstract color to a cube value is a
very quick operation.  To avoid the colorshifting problems, when a
cube is installed, the closest-match code will ignore the rest of
the colormap and only use colors from the cube.

The big problem is that X11 has no similar capability.  The only
way to obtain closest-color lookup in X (without writing application
code to grovel through the colormap) is to use a StaticColor visual.
(Personally, I consider this a serious defeciency in X11.)  You can
force a static color visual by starting openwindows with `-favorstatic'
(in which case you probably want `-cubesize large' too.)



-Pat


---
PMLashley	plashley@Sun.COM    SunSoft:NeWS/TNT
	"Those who do not know NeWS are doomed to recreate it - badly."