24-bit video workarounds

Mike Fitzpatrick wrote on Jul 07, 1999

> Thanks for the info.  We downloaded the file and have been able to run
> ximtool, after a fashion.  I really don't like the way this 8-bit/24-bit
> video interacts.  Is there a writeup somewhere on the best way of dealing
> with this problem?

	How to deal with 8/24-bits depends a lot on the platform, at least
in the details.  Writing this up is on my list of things to do but there's
never been time to do it right.  In general terms here's the deal:

	XImtool/SAOimage/SAOtng currently only run on 8-bit PseudoColor
visuals.  This is because the contrast scaling done by sliding the mouse
around is done by rescaling and rewriting the 8-bit colormap, with higher
depth visuals there is no colormap so the image itself would have to be
recomputed meaning the updates would be incredibly slow.  When ximtool was
first written 24-bit displays weren't all that common so this wasn't
incorporated right away, nowadays you can't spit without hitting a 24-bit
card and it's a bigger problem, we plan to fix this but it's a non-trivial
change.
	SAOtng has a hack to the Gterm widget which will make use of an
8-bit visual if it's available even if the default is 24-bits.  This only
works for those systems (not PCs) which support multiple depth visuals.
Even recent Solaris 7 systems no longer have this feature since the Open-
Windows server has apparently been dumbed down so it works on PC
platforms.  Any change to make the servers work with 24-bit would have to
support 16/24/32-bit TrueColor visuals directly, which leads straight to
the problem mentioned above.
	As for workarounds:  The simplest thing is to restart your X
server in an 8-bit mode when you need to use ximtool.  The details of how
to do this depend on the particular platform, for Linux/FreeBSD systems
using XFree86 this can be done with

        % startx -- -bpp 8

For Sun/Solaris systems, you'll need to start your X server in 8-bit Pseudo-
Color mode using something like

        /usr/openwin/bin/Xsun :0 -dev /dev/fb defclass PseudoColor

Note that you can put the above command in a ~/.xserverrc file.
	On XFree86 systems you can take advantage of the virtual consoles
and start multiple X servers, one at 24-bits and one at 8-bits and simply
switch between the two using the Alt keys.  This requires more memory but
is similar to using a virtual desktop, details on how to set this up can
be found at

     http://tdc-www.harvard.edu/software/saoimage/saoimage.16bit.html

	What I've found that works well, and again it depends on the
platform, is to set my Sparc Ultra 10 to use 8-bit visuals by default, but
start my Netscape using the 24-bit visual with a command like

	netscape -visual TrueColor

Certain version of Netscape (4.05 I think) had a bug where this didn't
work quite right, but when it does work you don't have NS sucking up all
the colors and can avoid the colormap flashing entirely.  If this isn't an
option, then you can limit the ximtool colors by defining resources such as

        XImtool*basePixel:      128
        XImtool*maxColors:      100
        XImtool*cmapInitialize: True

This limits ximtool to only 100 colors but minimizes conflicts.  You can
similarly set resources for Netscape or other applications to limit those
(whether it works depends in the version) colors.  
	On new systems like RedHat 6 which use Gnome/KDE as default
desktops you have to remember that these window managers (and others like
Enlightenment, AfterStep, or WindowMaker) are very color intensive and
in 8-bit mode you've used up most of the 256-cell colormap before you
even begin.  If you've limited the ximtool colors as above, don't have a
Netscape/XV/GIMP running and still see a conflict, check to see whether
the window manager icons (or window border gradients) are the cause.

Cheers,
-Mike

---

Last post on Jul 07, 1999