From: pmartz@dsd.es.com (Paul Martz)
Subject: Re: 24-bit Static color: will clients like it?
Nntp-Posting-Host: bambam
Reply-To: pmartz@dsd.es.com (Paul Martz)
Organization: Evans & Sutherland Computer Corp., Salt Lake City, UT
Lines: 38

In article <1993Apr26.123918.1@vxcrna.cern.ch>, roeber@vxcrna.cern.ch (Frederick Roeber) writes:
> I'm writing an X server for some video-generation equipment.  The
> hardware is "truecolor" in YUV space; in X terms it has a 24-bit
> static color visual.  I would really like to have the server just
> present this static visual, but I'm not sure if this will be 
> acceptable to "most" X clients.  The three problems I see are:
> 
>   1) The colormap, though huge, is static.
>   2) All pixels would be 3 bytes wide.
>   3) Because the hardware actually lives in YUV space, the
>      translation RGB->YUV will introduce some rounding error.

We tried to ship an X server once that only supported a 24bit
TrueColor visual. The main problems we encountered were:

	1) Clients written with logic like the following:

	    if (DefaultDepth() != 1)
		/* Assume default depth is 8bit */

	   These clients need an 8bit deep visual in the root window
	   to run correctly.

	2) Other clients didn't even bother to do that much, and just
	   outright assumed they had a *dynamic* visual class, with a
	   dynamic colormap. XStoreColors doesn't work on cmaps
	   associated with Static or TrueColor visual classes, but
	   many clients don't bother to check, they just start
	   throwing XStoreColor calls at you.

Though both are clearly client error, this is the case with so many
clients that it's easier for you to expose 8bit PseudoColor as a
default root window visual, than it ever would be for all these client
writers to change their clients to do the right thing.
--

   -paul	pmartz@dsd.es.com
		Evans & Sutherland
