Thread View: comp.sys.sgi.bugs
2 messages
2 total messages
Started by Dave Wiltzius
Fri, 18 Dec 1992 06:20
(Long) Reality Engine and colormap incompatibilities
Author: Dave Wiltzius
Date: Fri, 18 Dec 1992 06:20
Date: Fri, 18 Dec 1992 06:20
89 lines
4399 bytes
4399 bytes
The following is relevant only for IRIX 4.0 or later systems. Within the past few weeks I posted a "bug" with the Reality Engine regarding colormaps. Since then, I have sorted things out (I think!) with the help of several SGI folks, including the SGI hotline. The information I did get was in pieces and so I thought I would share a brief explanation of the problem and near solutions. A thorough explanation would be worthy of an online document that interested parties could FTP since I suspect this is an "advanced" topic of limited interest. Please note: I reference the Reality Engine (RE) as the distinguishing factor when the *real* factor is multiple hardware color maps. Here goes (I know this is going to be longer than I had hoped). Problem: A mixed-mode (Motif GUI with mixed-mode (GL) windows) application running on a PI flashes when the input focus goes between GL windows and non-GL windows. This is because the PI (and most SGI platforms) have only one hardware colormap that is shared for GL and X (Motif, etc) windows. Solution for PI: Set GL colors using XStoreColors on the default colormap (a different colormap could be used, but the problems are the same). That is, instead of setting GL colors with "mapcolor", have the application use XStoreColors. This could be done be redefining the "mapcolor" function to allocate (XAllocColorCells) and set (XStoreColors). Note that the allocation must allocate all the colors that GL will eventually want to set. Also, you don't want to step on the colors used by Motif, etc. 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. 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. The default X colormap is actually another hardware colormap. The former can be viewed using the "showmap" tool. The latter can be viewed using the "xshowcmap" tool. (I was incorrectly informed by SGI that simply each application gets a different colormap.) Please note that the RE (multiple hardware colormaps) neatly solves the problem that mixed-mode applications have on other platforms: GL code from a pure GL application (i.e. no X, Motif, etc) can be placed, without change, in a mixed-mode window. So the RE *requires* that the GL window use "mapcolor". Other SGI machines require that GL colors be set via XStoreColor on the default colormap if flashing is to be avoided. Hence it is possible to write portable code (i.e. dynamically adaptable to the platform it is running on) only if you have access to the sources so all "mapcolor" calls are left alone for the RE or converted to appropriate XAllocColorCells/XStoreColor calls. Which is often not the case if you are using commercial libraries (i.e. no source) based on GL. If the application is "pure" GL (uses winopen, etc instead of Motif), then only the GL colormap is used and of course the colors are set only using "mapcolor". 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). There may be a nifty solution to the problem of writing portable, mixed-mode applications. If a solution exists that would let me use GL libraries for which I do not have the source, I would be very interested in it. Frankly, I haven't mucked around much in graphics for about 8 years now. Things have changed. Different color maps for different windows? Must be some fast hardware. SGI may have bigger problems to address, but a short essay on colormaps in the context of Motif, GL, various SGI hardware platforms and life would be interesting to some of us. Or pointers to more info. Hope this helps. Dave Wiltzius LLNL wiltzius@llnl.gov
Re: (Long) Reality Engine and colormap incompatibilities
Author: Robert Keller
Date: Sun, 20 Dec 1992 07:11
Date: Sun, 20 Dec 1992 07:11
115 lines
4760 bytes
4760 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads