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

[Gary S. Moss VLD/VMB <moss>]

In article <1991Feb7.055317.21805 at odin.corp.sgi.com>, jsw at xhead.esd.sgi.com (Jeff Weinstein) writes:
|> 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.
Correct.

|> 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.
Admittedly, I'm naive about the internal workings of the Xlib routines and
X server, so I'll take your word on the data transfer part, I guess I was just
trying to rationalize the *extreme* slowness.   However, I imagine that
XCopyPlane() is significantly slower than XCopyArea() which is *really* slow
on the SGI.

If, as you say, SGI makes these routines suitably fast, it still doesn't
make 1 bit visuals redundant.  It would be cleaner to code programs that
only deal with 1 bit deep images (like text editors) if one could assume
that all servers support 1 bit visuals; I am not cognizant of the technical
issues that might come up in implementing a 1 bit visual on hardware that
doesn't support 1 bit raster ops, but it's something to consider.  From
my naive perspective, it seems that the details of dealing with the 1 bit
to 8 bit conversion could be handled by the server in software if the
hardware was not helpful in this regard.  Perhaps this is not compatible
with the X server model.

I hope that this doesn't sound like a complaint; SGI seems to be moving
swiftly with X, I'm just attempting to offer constructive suggestions.

Thanks for the info,
-Gary