home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sgi / bugs / 26 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!sgi!fido!not-for-mail
  2. From: rck@fangio.asd.sgi.com (Robert Keller)
  3. Newsgroups: comp.sys.sgi.bugs
  4. Subject: Re: (Long) Reality Engine and colormap incompatibilities
  5. Date: 19 Dec 1992 23:11:09 -0800
  6. Organization: Silicon Graphics, Inc., Mountain View, CA
  7. Lines: 115
  8. Message-ID: <1h16adINNhem@fangio.asd.sgi.com>
  9. References: <143761@lll-winken.LLNL.GOV>
  10. NNTP-Posting-Host: fangio.asd.sgi.com
  11.  
  12. wiltzius@anduin.ocf.llnl.gov (Dave Wiltzius) writes:
  13. :
  14. >Please note:  I
  15. >reference the Reality Engine (RE) as the distinguishing factor
  16. >when the *real* factor is multiple hardware color maps.
  17. :
  18.  
  19. quite true.
  20.  
  21. >Solution for PI: Set GL colors using XStoreColors on the
  22. >default colormap (a different colormap could be used,
  23. >but the problems are the same).  
  24. :
  25.  
  26. Ugh.  I don't believe that this is in any way "supported"
  27. behaviour.  Using X requests from within a pure GL (not 
  28. mixedmode) program is a gamble, and results are not defined,
  29. as far as I'm concerned (not an offical SGI spokesman).
  30.  
  31. >Now run this application on the RE (multiple hardware
  32. >color maps).  The colors set (by XStoreColors, as
  33. >noted above) for GL do not take affect.  
  34.  
  35. Right, see my comments above.
  36.  
  37. > This is because
  38. >all GL windows have their own hardware colormap whose
  39. >colors can only be set via the "mapcolor" function in
  40. >the GL library.  
  41.  
  42. Hmmm...  This reason is not quite right.  
  43.  
  44. On the RealityEngine (what follows is VERY RealityEngine dependant)
  45. typically, each GL window has it's own Display ID, ie. each pixel of 
  46. that GL window is tagged with it's ID.  This ID controls the display
  47. aspects of that particlar window, like which of the front/back/left/right
  48. buffers is currently being displayed.  Another display attribute the ID
  49. controls is which HARDWARE colourmap the particular GL window's colourindex 
  50. values are interpreted by.
  51.  
  52. > The default X colormap is actually
  53. >another hardware colormap.  
  54.  
  55. No.  The default X colourmap is a data structure in the X server.  It
  56. has no more lien on a hardware colourmap than any other X colourmap.
  57.  
  58. Aside:  
  59.     The GL colourmap is implemeted via a thin veneer over a 12bit 
  60.     PseudoColor X colourmap.
  61.  
  62. >(I was incorrectly
  63. >informed by SGI that simply each application gets a different
  64. >colormap.)  
  65.  
  66. Each application that requests a different X colourmap (VIRTUAL) gets it.
  67. How many of these colourmaps can be simultaneously installed is very
  68. hardware dependant.  Perhaps this is what the SGI person meant.
  69.  
  70. >So the RE *requires* that the GL window use "mapcolor".
  71.  
  72. A pure GL program should always use mapcolor(), whether is destined for
  73. a RealityEngine or not.
  74.  
  75. >Other SGI machines require that GL colors be set
  76. >via XStoreColor on the default colormap...
  77.  
  78. NO!  (sorry to nit-pick so much on this)  
  79.  
  80. >...if flashing
  81. >is to be avoided.  
  82.  
  83. There are other less risky ways around flashing...
  84. Let us first assume that the multiple colourmap hardware configuration 
  85. completely takes care of flashing between the GL colourmap and the 
  86. default X colourmap.  Then, we are in search of ways to reduce flashing
  87. on systems with only one hardware colourmap.
  88.  
  89.     1 - Write your GL applications in RGB mode.
  90.     Since the GL is not using the colourmap, the default X colourmap
  91.     has the run of the hardware.
  92.         
  93.     2 - Run the X server in RGB mode.
  94.     Since the default X colourmap is based on 24 TrueColor (not really 
  95.     a colourmap), the GL colourmap can have the run of the hardware.
  96.  
  97.     3 - Allocate your GL colours from 4095 down.
  98.     The default X colourmap gets allocated from index 0 on up.  If your
  99.     GL program uses entries from index 4095 on down, you avoid (or
  100.     even eliminate) conflicts resulting in flashing.  This works really
  101.     well if your GL program completely avoids indices 0-255, where the
  102.     default X 8bit colourmap sits.
  103.  
  104.     4 - Investigate the -pseudomap option to Xsgi (check out the man page)
  105.     :
  106.  
  107. >In summary, on the RE all GL windows use the GL
  108. >hardware colormap (viewed by showmap tool).  All
  109. >X (Motif, etc) windows use the default X hardware
  110. >colormap (viewed by xshowcmap tool).
  111.  
  112. Not at all.  
  113.  
  114. By design, the IRIS GL (current "pure" GL) shares one colourmap among all 
  115. the GL applications.  This maybe called the GL colourmap (virtual), but it 
  116. has no absolute right to any hardware colourmap.
  117.  
  118. X clients can create any colourmaps they want, or share in the default one,
  119. but they neither have any right to a particular hardware colourmap.  
  120.  
  121. At runtime, depending on who (GL, X clients) wants what, the X server decides
  122. which virtual colourmap gets mapped into a hardware colourmap.  
  123.  
  124. time to trim the tree...
  125.  
  126. ...robert
  127.