Re: [AD] xwin color-conversion

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> i have spent two days now examining and experimenting with the xwin driver
> to see if the assembler color-conversion can be integrated in SOME cases.
> (task listed in todo file) but there are cases where remote and local
> endianness is different, (which can be handled by a slow visual method)
> and much more commonly bit-shifts which doesn't match allegro's standard,
> typically RGB->BGR conversion, something which is currently handled by
> rmap, gmap and bmap.

I tried to tackle this in the past, but never got around to really writing 
something.  Note that, thanks to Angelo, there are now generic C color 
conversion routines as well (see src/misc/ccolconv.c).

> so... questions for daring souls:
>
> 1) can we assume that x-windows visuals for the most doesn't use weird
> bit-encodings/bit-masks (such as 6:6:4 for 16 bit, instead of the normal
> 5:6:5) for standard colordepths?

I'd say that we can't assume anything if we want to be portable on the least 
mainstream Unix platforms.  But do we really need to do assume anything?
I think we can simply check that the format is supported by the generic 
routines and, if it is not, piggyback on the routines in xwin.c.  Of course 
this means that we can't eliminate code in that file.

> 2) what's the best method for handling non-allegro-compatible bit-shifts?
>     - keep the existing fast visual methods which handles weird bit-shifts
> and bit-masks.
>     - add new routines to allegro's color conversion blitters that can
> handle weird bit-shifts and perhaps bit-masks.

I'd say the former.  The weird formats probably do not deserve to have code 
specialized for them.

> 3) the purpose and function of cmap. i am still just very much guessing
> here. but as far as i can tell it is used to convert RGB values to RBG
> values found in the colormap, which seems to have a max size of 4k
> entries. and that the visual is paletted and over 8 bits is going to give
> me a headache soon unless someone explains it to me.

cmap is the RGB -> 8-bit conversion channel:

  /* Make fixed palette and create mapping RRRRGGGGBBBB -> palette index.  */
      for (r = 0; r < 16; r++) {
	 for (g = 0; g < 16; g++) {
	    for (b = 0; b < 16; b++) {
	       color.red = (r * 65535L) / 15;
	       color.green = (g * 65535L) / 15;
	       color.blue = (b * 65535L) / 15;
	       XAllocColor(_xwin.display, _xwin.colormap, &color);
	       _xwin.cmap[(r << 8) | (g << 4) | b] = color.pixel;
	    }
	 }
      }


When the visual is paletted and the Allegro color format is not, we have:

 Allegro color space   _xwin.cmap     visual          _xwin.colormap   screen
        RGB           ----------->   8-bit index   ---------------->    RGB

-- 
Eric Botcazou