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

[Maxim Levitsky]

On Monday, 21 January 2008 10:53:03 Barton C Massey wrote:
> 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.
You are right, this is the thing I am worried about.

Suppose my app does some drawing using very close colors, and fills the colormap with say lots of green shades.

Then it is asked to render a 24-bit pixmap, I use some sort of 
dithering to convert it to 8-bit image.

But then the rendering will have hard time finding even approximate colors,
since the colormap is polluted.

I think that the colors that are used for drawing aren't that important.
(They are all mostly just shades of black, and about 5~6 shades are enough I think)
But colors that are used for rendering of images, especially 16-24 bit ones are important,

In other words, by allocating the palette colors to drawing, I create an 'optimized' palette for drawing. It is even possible that I will see the exact colors that were used in drawing.

But this palette isn't optimized for rendering of images, so they will look worse.

And even if the colormap is free, the first time I render a 16/24 bit image, the rendering will fill the palette and all the following drawings won't be accurate, and will probably look even worse.

Thus why not, preallocate the palette in the neutral way, and get always a semi-optimal drawings, 
instead of some perfect drawings, but then a sub-optimal drawings.

Anyway those old days were so hard, all those encoding were a pain, while now the Unicode makes it easy, and the same for colors, the advantage of using colormap instead of plain RGB, it quite hard to achieve it seems.

Although on the other hand old X applications hardly use anything but the monochrome pixmaps, thus they probably don't even allocate the colors, but use just the BlackPixel, and WhitePixel.

But I want to create a modern-looking toolkit, to make it look like the 'Plastic' style of QT, or something similar, plus I want to use colorful icons, and most importantly I will make it theme-able, so other styles will be possible as well.

>
> > Since this is very obsolete I won't go this way.
> 
> I'm not sure what you mean by "very obsolete".  If you mean
I mean I was worried you say me that I am trying to solve non-problem,
and I should not pay much attention to colormaps.
> 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.
> 
....
> 
> 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
> 

Big thanks for help,
	Best regards,
		Maxim Levitsky