Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: ekberg@asl.dl.nec.COM (Tom Ekberg)
Newsgroups: comp.windows.x
Subject: Re: Special Colormap Allocation
Message-ID: <9102191531.AA24359@asl.dl.nec.com>
Date: 19 Feb 91 15:31:20 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 19

From: jeff@osc.edu (Jeff Faust):
 >                   XAllocColor() and XAllocColors() come close but
 > there is now [sic] way to detect unallocated colors from alloced colors. I
 > don't want my code to bother to match what are garbage values in the
 > colormap. Does anyone have any ideas about how to improve this
 > situation?

I have done a bit of work with allocating colors when only a small number (256)
are available.  Specifically, trying to display multiple GIF files at the same
time when the total number of colors needed exceeds 256 and get a reasonable
result.  Anyway, the approach I used distinguished read-only pixels from
read/write pixels.  What you can do is to is to attempt an XStoreColor on a
pixel.  If the store succeeds then you know that you have a read/write pixel.
If you get a BadAccess error then you have an unallocated or a read-only pixel.
Of course, if you allocate all cells in the colormap first (assuming you are
using a PseudoColor visual class) then if you get a BadAccess from a
XStoreColor then you know you have a read-only pixel.

  -- tom, ekberg@aslss02.asl.dl.nec.com (x3503)