[cairo] Color cube stuff for pseudo-color support
keithp at keithp.com
Fri Feb 29 18:10:33 PST 2008
So, you want to allocate a color cube. And you want to share it among
Sharing is only possible if everyone allocates exactly the same colors
using read-only pixels. But, you can only allocate one read-only pixel
at a time. So, you don't get to know up-front how many colors you can
What you can do is allocate a pile of pixels read-write, then free them
when you know how many pixels are available. Yuck, but it will work. The
code for doing this work is available in the xstdcmap client.
The second trick here is figuring out whether some other cairo
application has already allocated a suitable color ramp. You can't use
the read-write trick as you won't align with other cairo applications.
And, allocating colors read-only will make fail-over to smaller cube
Here's my suggestion (untested). Use a root window property to indicate
what kind of color cube has been allocated. If that property is present,
just allocate the indicated colors one at a time (read-only). If that
fails, free the allocated colors, then use the read-write trick to
figure out how much space is free in the colormap and reset the property
to indicate what color cube was successfully allocated.
As to the precise colors to use, Render uses a fairly small cube, and a
gray ramp. The ramp helps provide extra resolution when drawing text;
the cube provides fairly minimal color coverage. The allocation code has
a 'size' parameter which limits how many colors will be allocated.
I'd say that the colormap stuff should probably be done with the server
grabbed or you'll probably have terrible race problems.
The X server has a fairly inefficient mechanism for translating from RGB
value back to pixel value. It constructs, in the most obvious way
possible, a 3-dimensional array that maps a sub-set of the bits in each
component back to the closest pixel value allocated. While the mapping
is obviously fast, the construction of the array is not. A non-quadratic
mechanism is clearly necessary when it will be executed at each
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.cairographics.org/archives/cairo/attachments/20080229/03b7dfdf/attachment.pgp
More information about the cairo