dj@eng.sun.COM (Deron Dann Johnson) (03/07/90)
I have a question about a passage in the O'Reilley Xlib reference manual (1988) for XAllocColor: "If no matching cell exists but there are unallocated cells, a cell is allocated to match the specified RGB values. If no matching cell exists and there are no unallocated cells, the closest available colorcell that has already been allocated (by this or any other client) is returned." I believe that this statement of the behavior of XAllocColor is incorrect, for the following reason: 1) It does not explicitly state that this applies only to dynamic visuals. (But it's pretty obvious, so this is not that bad). 2) No mention is made of this in the R4 protocol document. In fact, the protocol does not explicitly define what the behavior should be in this situation. 3) The R4 Xlib documentation also does not explicitly define this behavior. 4) The R4 sample server code doesn't not implement this behavior. Instead, a BadAlloc is returned in this situation. All of these lead me to believe that the behavior documented in O'Reilley is incorrect, but I wanted to confirm this with others because the described behavior is somewhat intuitive. Theory: this is a remnant from earlier versions of the protocol?
apn1713@cec1.wustl.edu (Adrian P. Nye) (03/10/90)
You're right, the description of the operation of XAllocColor in the first edition of the O'Reilly Xlib Programming Manual is not completely correct. Here is the text from the Second edition, which is going to the printer on March 12th. "If the display hardware has an immutable hardware colormap, the entire colormap will be read-only, and the closest cell that exists will be returned. Otherwise, the colormap is read/write, and may have some read/write cells, some read-only cells, and some unallocated cells. If a read-only cell exists that matches the requested RGB values, that cell is returned. If no matching cell exists but there are unallocated cells, a cell is allocated to match the specified RGB values. If no matching cell exists and there are no unallocated cells, XAllocColor returns a Status of zero (it does not return the closest available read-only colorcell that has already been allocated). If it succeeds, XAllocColor returns nonzero." The Second edition of Volumes 1 and 2 covers R3 and R4 and have a much better description of color handling. ________________________________________ Adrian Nye (617) 354-5800 O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks 90 Sherman Street, Cambridge, MA 02140 UUCP: uunet!ora!adrian ARPA: adrian@ora.uu.net
mikep@sco.COM (Mike Patnode) (09/27/90)
It seems that XAllocColor() will not try to approximate colors on
PseudoColor displays when none are available. Given that you have a
full colormap, and the color you specifically want does not exist,
shouldn't XAllocColor() return the closest read-only color value
available?
In mit/server/dix/colormap.c, AllocColor() only does the following:
case PseudoColor:
if (FindColor(pmap, pmap->red, entries, &rgb, pPix, PSEUDOMAP,
client, AllComp) != Success)
return (BadAlloc);
break;
FindColor either finds the preexisting color, or allocates a new one.
Shouldn't FindBestPixel() be called when FindColor() fails?
Note that O'Reilly claims XAllocColor() should work this way, while the
Red Book sort of side steps the issue. Is the O'Reilly book just wrong?
--
Mike Patnode The Santa Cruz Operation
SCO Software Engineer 400 Encinal Street
{ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900
(408) 458-1422 Santa Cruz, CA 95061rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/02/90)
shouldn't XAllocColor() return the closest read-only color value
available?
It only does this for Static visuals, not dynamic ones. We could have
long arguments about why this semantics and not the other. The truth
is that both semantics should have been provided, rather than trying to
choose one.
Note that O'Reilly claims XAllocColor() should work this way, while the
Red Book sort of side steps the issue. Is the O'Reilly book just wrong?
Yes, although it is an understandable mistake.