Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: Gray-scale demos wanted!
Message-ID: <1340@acorn.co.uk>
Date: 5 Jan 90 14:56:57 GMT
References: <9001050139.AA21346@bird.visual.uu.net>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 25

In article <9001050139.AA21346@bird.visual.uu.net> mjb@visual.UUCP writes:
>We will be showing a gray-scale (2 planes) X terminal at Uniforum.

Interesting.  What pixmap format do you use?  I have a server which supports
visuals with depths of 1,2,4 and 8 (plus pixmaps of depth 16,24,32), however
I ran into the problem with depth 2 that the only valid bits-per-pixel values
are {1,4,8,16,24,32} - ie no 2!  The ``correct'' solution is to use 4, but
this means that there is less advantage in using a depth of 2 - the internal
implementation of the (my) ddx layer means that it would be inconvenient
using a bits-per-pixel of 4 with an *internal* bits-per-pixel of 2 (ok, I
admit that it is only nessary to do the conversion at the GetImage/PutImage
interface, but this is still a significant amount of work for what seemed
like little gain).

Does anyone know how any X implementations for the NeXT workstation handle
this problem?  My current solution is not to support depth 2 by default, and
when it is supported the bits-per-pixel is 2!  Obviously this doesn't 
conform to the protocol.  Are any other vendors thinking of depth 2 support?

Why were the pixmap *formats* restricted to those 6 values, while the 
depths were left unrestricted?  Is it an attempt to reduce the work required
in a general purpose application?  If so why was format 2 excluded - 
historical reasons?

John Bowler (jbowler@acorn.co.uk)