Glynn Clements <glynn.clements(a)virgin.net> wrote:
I'm pretty sure that XAllocColor() just returns the closest
colour on
"fixed" visuals (StaticGray, StaticColor, TrueColor). It only actually
"allocates" anything on visuals which have some form of programmable look-up
table (GrayScale, PseudoColor, DirectColor).
Correct. The cells are allocated read-only, can be shared by multiple
clients. The actual color spec used and returned is the closest one supported
by the hardware.
DirectColor is the case where I never managed to understand the
semantics of XAllocColor(). I'm not sure that anyone else does either;
Here's my understanding: in DirectColor, you think in terms of color
planes rather that in terms of color cells. For instance, under a DirectColor
24 visual (8/8/8), due to the way pixels index the color cells, you can have
only 256 tints of each primary per colormap, and these tints are the same for
all colors in your colormap. Note that your hardware might know more than 256
tints in each primary, but can only handle that ammount at the same time[1].
Given this, XAllocColor works by looking at each primary in turn: if
you've already allocated enough different colors so that you've exhausted the
red planes, all X can do is use an existing value. Otherwise, it can allocate
a new one. In all cases, that builds the corresponding bitfields in the pixel
value, and this not only affects the color you're allocating (as in
PseudoColor visuals) but also *all* subsequently allocated colors that share
the same value for the red mask part. You then repeat the process for the
other components.
Footnotes:
[1] that's also why many displays support several TrueColor visuals of the
same depth: they implement different gamma curves of stuff like that.
--
Didier Verna, didier(a)lrde.epita.fr,
http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org