Re: ABI rules on accessing colormap->colors?

["Pawel S. Veselov" <Pawel Veselov Sun COM>]

Peter,

On Mon, Sep 15, 2003 at 11:18:03PM +1000, Peter Zelezny wrote:
> > > Basically, I'm doing a:
> > >    gdk_colormap_alloc_color (cmap, color, TRUE, TRUE);
> > > But on a most 8-bit PseudoColor displays, it fails, since the cmap is
> > > often full. So I fall back to traversing the cmap->colors to see which is
> > > the closest colour available. It gives pretty good results.
> > >
> > > I tried calling gdk_colormap_alloc_color() with the "best_match" arg TRUE,
> > > hoping this would be done for me, but it is not.
> > Well, why don't you debug that? If you're right and there is a bug
> > there, then we can discuss workarounds, once we know what that bug is.
> I didn't realize it could be a bug, I don't know much about Visuals.
>
> Here's a testcase: http://213.197.30.23/cmap.c

I ran this testcase on a freshly created 8bit server, and it says success.
Apparently, by default, server allocates about 234 colors, from 256 possible.
That is probably how much colors does it have in it's database.

> Comments at the top should give anyone an easy way to reproduce it. When I
> run the program, it fails everytime. No problem in TrueColor however.

Everytime meaning on all other displays but TrueColor ? Hardly believable.
As for PseudoColor visuals - very likely, since there is only 22 colors
left unallocated when server starts, and other greedy X clients use them all
really fast.

On TrueColor, neither RW cells, nor bestmatch have any meaning, since the
pixel value is derived directly from the color components values.

If you need a lot of colors, consider installing your own colomaps.

You also probably don't need RW cells, it only makes sense for PseudoColors
type visuals, where you can recolor your window, by just changing the pixel,
instead of replacing the actual pixel value. If you intend your client to
work on different visuals, you definitely don't need RW cells.