From: rck@fangio.asd.sgi.com (Robert Keller)
Newsgroups: comp.sys.sgi
Subject: Re: Hardware/Colormap differences?
Date: 21 Aug 92 16:58:17 GMT
Organization: Silicon Graphics, Inc., Mountain View, CA

In article <Bt8zts.EFz@news.cso.uiuc.edu> dweber@ncsa.uiuc.edu writes:
>When I run this on the VGX, unless the mouse is in the window, the first N
>(128?) polygons are weird colors.  Once the mouse is moved into the window,
>the polygons are correctly colored, but now the rest of the screen's colors
>are freaky.
>
>When I run this program on our Indigo, the colormap is loaded correctly and
>the gl window gets filled with grayscale polygons, as it should *WITHOUT*
>the rest of the screen changing!  

The VGX and Indigo have two completely different graphics architectures.
One on the differences includes the way colourmaps were implemented.  

X allows applications to thinks of colourmaps as exclusive resources, ie
everyone can have their own.  Once you get down to implementing this on 
hardware, the hardware constrains dictate what happens.

The VGX has one hardware colourmap to share amoung all its windows 
(and visuals).  Naturally, only one colourmap can be truly be installed 
at a time.    

The Indigo (entry, XS, XS24, elan) has multiple hardware colourmaps.  This 
means that two (or more) X colourmaps can be simultaneously installed in 
the hardware.

Your observations lead me to believe that you are asking for more than
one X colourmap to be installed at a time.  Since the "colourmap focus"
follows the pointer (in 4Dwm), whichever window you move into gets its 
colourmap installed on the VGX, thus causing "flashing".  The Indigo 
has multiple hardware colourmaps, therefore your X colourmaps can live 
in the hardware concurrently.

>I *want* to be able to change the gl colormap *without* the rest of the 
>screen flaking out.

There is hope, you could try using X and GL colourmap entries that do 
not conflict with each other.  There is an optimization in the colourmap
installation code that causes unallocated X colourmap entries not to 
be installed in the hardware.  This pretty "hit-and-miss".

An even better option would be to investigate the "-pseudomap" option to 
the X server.  The relevant sections of the Xsgi(1) man page is included 
below:

          -pseudomap string
                  tells how to initialize default PseudoColor
                  colormaps.  String must be one of gl, envm, pseudo,
                  or 4sight.  The setting determines the number of
                  cells preallocated by the server for sharing
                  ReadOnly by clients.  All preallocated cells contain
                  colors which match those in the default GL
                  "colorindex" colormap.  If more cells are
                  preallocated, the default map and maps used by the
                  GL will match better, but fewer cells will be
                  available for allocation by clients.  gl
                  preallocates cells 0-15.  envm preallocates cells
                  0-15 and 32-255.  pseudo preallocates only
                  WhitePixel and BlackPixel.  4sight preallocates 0-15
                  and 32-55.


Or, you could investigate changing your X server's root visual on the VGX 
to 24 bit TrueColor.  See the -depth, -class options in the aforementioned 
Xsgi(1) man page. (-depth 24 -class TrueColor)

    (Aside: edit /usr/lib/X11/xdm/Xservers to add these options)

>How is it that the Indigo is capable of doing
>this, yet the "better" VGX is not?  

The VGX was designed when SGI's windowing system was NeWS, not X.  The 
Indigo was designed with X very much in mind.  

You can rest secure in the knowledge that the RealityEngine has so many 
hardware colourmaps, it'll make your head swim.

...robert
Newsgroups: comp.sys.sgi