home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!mips!odin!fido!fangio.asd.sgi.com!rck
- From: rck@fangio.asd.sgi.com (Robert Keller)
- Newsgroups: comp.sys.sgi
- Subject: Re: Hardware/Colormap differences?
- Message-ID: <orssks0@fido.asd.sgi.com>
- Date: 21 Aug 92 16:58:17 GMT
- References: <Bt8zts.EFz@news.cso.uiuc.edu>
- Sender: news@fido.asd.sgi.com (Usenet News Admin)
- Organization: Silicon Graphics, Inc., Mountain View, CA
- Lines: 77
-
- 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
-