Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Color maps....
Message-ID: <9104022055.AA12037@lightning.McRCIM.McGill.EDU>
Date: 2 Apr 91 20:55:27 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 23

>> To do this, you have to allocate read/write cells instead of
>> read-only cells (minor wart, but more or less unavoidable).  What
>> you actually want is to have a group of color cells that have all
>> but four bits equal, then those four bits give you the sixteen
>> combinations you want.  The routine to allocate colormap cells this
>> way is XAllocColorCells; you would want to call it with nplanes=4
>> and npixels=1.

> In requesting for read/write cells, should n't one ensure that a
> PseudoColor/DirectColor visual is available at all , before using
> AllocColorCells ? Probably too important to be explicitly mentioned.

Well yes.  If you want to have any say at all in the way colors are
laid out in the colormap, you need a dynamic visual (ie, PseudoColor,
DirectColor, or - though useless in this case - GrayScale).  If nothing
but static visuals are avaiable, the original problem is either trivial
or impossible, depending on whether the colormap has the colors laid
out as you want them or not.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu