Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!brl.mil!moss
From: moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>)
Newsgroups: comp.sys.sgi
Subject: Support of 1 bit visuals from SGI's X server.
Keywords: X
Message-ID: <15113@smoke.brl.mil>
Date: 6 Feb 91 20:47:00 GMT
Sender: news@smoke.brl.mil
Reply-To: moss@brl.mil
Organization: Ballistic Research Laboratory
Lines: 22

I've just finished modifying Rob Pike's "sam" editor to work on X servers
whose default visual is other than 1 bit deep.  As far as I could tell
from the Xlib routines, the X server under IRIX 3.3.1 does not support
a 1 bit deep visual, only an 8 bit visual.  I generalized the code to
use a multiple bit deep visual when a 1 bit visual is not available,
however the result is way too slow to be usable on the SGI 240/GTX.  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 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?

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

Thanks,
-Gary