[Xcb] [Semi-off-topic] Few questions regarding X programming

[Barton C Massey]

In message <200801202327.02366.maximlevitsky at gmail.com> you wrote:
> There are two methods to deal with colormaps:
> 
> 1. The old fashion way:
> 
> Treat AllocColor like pixel=RGB(r,g,b).
> All colors that are required for drawing are allocated
> this way, and are (possibly) cached.
> 
> The pixmaps are also 8-bit, and have a small colormap attached to them.
> When using them, first add their colors to palette.
> 
> But if the pixmaps are 16bit or higher images, thus pixels
> contain RGB data instead, then ether the toolkit has to
> scan whole pixmap to see what colors were actually used
> which is slow, or still have a colormap attached to it.

Most X rendering is done through the drawing APIs.  In this
case, the pixel values you get back from AllocColor have
semantic meaning, and there are typically easy ways to store
and index them.  This doesn't seem to be the case you are
worried about.

For images, which seems to be what matters to you, things
are a bit scarier.  People *may* still ask you to render
24-bit true-color images on 8-bit pseudo-color or even 1-bit
monochrome displays.  You will typically need to use some
combination of resampling and dithering, hopefully provided
by a friendly library, to get the rendering done properly.

> Since this is very obsolete I won't go this way.

I'm not sure what you mean by "very obsolete".  If you mean
that this kind of hardware is obsolete, and that you can
thus just choose to lose on these devices, you are probably
right.  All but the most recent generation of small portable
devices still use monochrome, grayscale, or
limited-resolution color.  But these devices are mostly too
small to run X anyhow.

> 2. The true color emulation:
> 
> Allocate all/most entries in colormap for equally spaced
> colors, save the resulting pixels in a array, And then use
> this array for all drawing, convert all pixmaps to use
> those pixels on the fly.

Note that the phrase "equally spaced colors" is fraught with
much peril.  And "convert all pixmaps to use those pixels on
the fly" is the same problem as described above---so why not
allow the conversion to choose its colormap as well?

> I will eventually implement #2, but for now I will just
> use TrueColor visuals.  Btw my video card supports 8-bit
> TrueColor visuals when used in 256 color mode.  Strangely
> an old S3 ViRGE also supports TrueColor visuals in 8-bit
> mode.

8-bit TrueColor visuals are horrible unless you choose them
crazy well and dither extensively.  If you want to support
8-bit displays, it is arguably easier to do the right thing
as described in #1 than to do #2.

If you are willing to ignore monochrome and 8-bit displays,
then supporting TrueColor in the obvious way---truncate each
8-bit color component as needed---is probably just fine:
16-bit 6:6:4 or 5:5:5 turns out to be "close enough" for
most things.

Hope this helps,

    Bart