Support of 1 bit visuals from SGI's X server.

[Jeff Weinstein]

In article <15113 at smoke.brl.mil>, moss at brl.mil (Gary S. Moss (VLD/VMB)
<moss>) writes:
> Not
> only is XCopyPlane() required to tranform textures and cursor bitmaps
> into 8 bit pixmaps, but 8 times as much data needs to be sent to the server
> whenever anything is drawn.

  I don't understand the above comments.  Your bitmaps should be stored in
the X server as 1 bit pixmaps, then copied to the screen using XCopyPlane()
from the 1 bit pixmap to the 8 bit window.  The hardware actually gets 1
bit of data per pixel and automatically expands it to 8.  There is no reason
for any 8 bit per pixel data to be sent anywhere in this scenario.

> I realize that part of the problem is that sam uses a low-level interface
> to the Xlib routines in order to emulate the DMD graphics routines.  For
> instance, the bitblt routine uses XCopyArea(), but this is lightning fast
> on monochrome *and* color Suns.  Given that the SGI GL and supporting
> hardware was not designed with bitblt-style operations in mind, has the X
> server been optimized to do the best it can on the 4D platforms?

  In the 3.* releases of IRIX the X server has not been tuned to take full
advantage of the hardware.  It has been constrained by having to be both
a NeWS and GL client program.  This results in many layers of software,
and much useless data copying.

> Does anyone at SGI know if any plans exist for resolving this performance
> issue in IRIX 4.0?

  Just about all X performance problems are being resolved in IRIX 4.0.
CopyPlane should perform well.  We have seen dramatic speedups in many 
common X operations.

	--Jeff

Jeff Weinstein - X Protocol Police
Silicon Graphics, Inc., Entry Systems Division, Window Systems
jsw at xhead.esd.sgi.com
Any opinions expressed above are mine, not sgi's.