🚀 go-pugleaf

wiltzius@anduin.ocf.llnl.gov (Dave Wiltzius) writes:
:
>Please note:  I
>reference the Reality Engine (RE) as the distinguishing factor
>when the *real* factor is multiple hardware color maps.
:

quite true.

>Solution for PI: Set GL colors using XStoreColors on the
>default colormap (a different colormap could be used,
>but the problems are the same).  
:

Ugh.  I don't believe that this is in any way "supported"
behaviour.  Using X requests from within a pure GL (not 
mixedmode) program is a gamble, and results are not defined,
as far as I'm concerned (not an offical SGI spokesman).

>Now run this application on the RE (multiple hardware
>color maps).  The colors set (by XStoreColors, as
>noted above) for GL do not take affect.  

Right, see my comments above.

> This is because
>all GL windows have their own hardware colormap whose
>colors can only be set via the "mapcolor" function in
>the GL library.  

Hmmm...  This reason is not quite right.  

On the RealityEngine (what follows is VERY RealityEngine dependant)
typically, each GL window has it's own Display ID, ie. each pixel of 
that GL window is tagged with it's ID.  This ID controls the display
aspects of that particlar window, like which of the front/back/left/right
buffers is currently being displayed.  Another display attribute the ID
controls is which HARDWARE colourmap the particular GL window's colourindex 
values are interpreted by.

> The default X colormap is actually
>another hardware colormap.  

No.  The default X colourmap is a data structure in the X server.  It
has no more lien on a hardware colourmap than any other X colourmap.

Aside:  
    The GL colourmap is implemeted via a thin veneer over a 12bit 
    PseudoColor X colourmap.

>(I was incorrectly
>informed by SGI that simply each application gets a different
>colormap.)  

Each application that requests a different X colourmap (VIRTUAL) gets it.
How many of these colourmaps can be simultaneously installed is very
hardware dependant.  Perhaps this is what the SGI person meant.

>So the RE *requires* that the GL window use "mapcolor".

A pure GL program should always use mapcolor(), whether is destined for
a RealityEngine or not.

>Other SGI machines require that GL colors be set
>via XStoreColor on the default colormap...

NO!  (sorry to nit-pick so much on this)  

>...if flashing
>is to be avoided.  

There are other less risky ways around flashing...
Let us first assume that the multiple colourmap hardware configuration 
completely takes care of flashing between the GL colourmap and the 
default X colourmap.  Then, we are in search of ways to reduce flashing
on systems with only one hardware colourmap.

    1 - Write your GL applications in RGB mode.
	Since the GL is not using the colourmap, the default X colourmap
	has the run of the hardware.
		
    2 - Run the X server in RGB mode.
	Since the default X colourmap is based on 24 TrueColor (not really 
	a colourmap), the GL colourmap can have the run of the hardware.

    3 - Allocate your GL colours from 4095 down.
	The default X colourmap gets allocated from index 0 on up.  If your
	GL program uses entries from index 4095 on down, you avoid (or
	even eliminate) conflicts resulting in flashing.  This works really
	well if your GL program completely avoids indices 0-255, where the
	default X 8bit colourmap sits.

    4 - Investigate the -pseudomap option to Xsgi (check out the man page)
    :

>In summary, on the RE all GL windows use the GL
>hardware colormap (viewed by showmap tool).  All
>X (Motif, etc) windows use the default X hardware
>colormap (viewed by xshowcmap tool).

Not at all.  

By design, the IRIS GL (current "pure" GL) shares one colourmap among all 
the GL applications.  This maybe called the GL colourmap (virtual), but it 
has no absolute right to any hardware colourmap.

X clients can create any colourmaps they want, or share in the default one,
but they neither have any right to a particular hardware colourmap.  

At runtime, depending on who (GL, X clients) wants what, the X server decides
which virtual colourmap gets mapped into a hardware colourmap.  

time to trim the tree...

...robert