From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : Brian S. Julin <bri@tull.umassp.edu>
  Date: Sat, 03 Jul 1999 16:32:07 +0000

Re: Palette proposal

Brian S. Julin wrote:
> 
> On Sat, 3 Jul 1999, Marcus Sundberg wrote:
> > > Now, this is less information than really needed by apps.  This
> > > may be due to an assumption that the size of the palette ==
> > > 2^bpp -- that assumption is wrong.
> >
> > No it's not.
> > Size of the palette for GT_STATIC_PALETTE and GT_PALETTE is
> > (1 << GT_DEPTH(graphtype)) entries.
> 
> This is OK by me as long as it's official and documented.  Graphtypes
> can just be added if/when the case I described is needed.  Can we
> then document and officialize that GT_PALETTE and GT_STATIC_PALETTE
> graphtypes have the above property, and that they also have the property
> that this is considered correct usage:
> 
> ggi_pixel p;
> ggi_color c;
> p = ggiGetPixel(vis, x, y);
> c = pal[p];
> 
> As long as this behavior is documented I'm happy.

Sure, the above is perfectly valid code.

> > > In reality (I checked), ggiGetPalette seems to return 0 when the start (s)
> > > parameter is a valid palette index (on my system this seems to be off by
> > > 1 ?!?).
> >
> > What do you mean "off by one" ?
> 
> Returns 0 for 257 values of idx (idx=0 and idx=256 both return 0)
> on a 8bpp visual.

Oh, that's just a side effect of the below code:
	if (start < 0 || start+len > COLOR_PALPRIV(vis)->numcols) return -1;
No reason to change it as calling Set/Get palette with an invalid
'start'
value yields undefined results.

> > Having ggtGetPalette() return the last index into the CLUT is a good
> > idea though.
> 
> How about having both ggiGetPalette and ggiSetPalette do that on
> GT_PALETTE visuals,

Well, if you think it's necessary and are willing to change all
setpalette functions accordingly I won't mind. ;)

> but on visuals with GT_STATIC_PALETTE, ggiSetPalette always returns -1.

Already true, because if the palette is static opcolor->setpalvec is
not initialized.

> The documented return code for ggiSetPalette
> (the first index set) would remain the same when GGI_PALETTE_DONTCARE
> is used.

This is documented somewhere? I can not recalled something like
that being even discussed.
Note that GGI_PALETTE_DONTCARE is free to re-order color entries
as it likes, so the first index set is about as useful information
as (random() % palsize)...

> > If you are not happy enough with GGI_PALETTE_DONTCARE you can implement
> > an environment variable GGI_PALETTE_DC_NICE which only changes
> > unallocated colors in the colormap on X and Xlib targets.
> 
> I'd rather implement a new graphtype, because this really doesn't
> deal eloquantly with the case where you have both static and changable
> CLUT entries not necessarily sequential.  I'd use the rules
> proposed, but they would only apply to that new graphtype.
> 
> To give a pitance more justification, consider the following features:
> 
> 1) VGA hardware border color is taken from a CLUT entry.  It's inadvisable
> to draw pixels in the color, and altering the color is best left to
> an extension function.  Same with 2bpp sprite colors robbed from
> main CLUT.
>
> 2) Some 2bpp sprites have both fixed entries (the transparent/inverse colors)
> and their very own settable CLUT entries.

This sounds like some quite special cases to me.
In any case something as major as adding a new graphtype should not
be done until there is something that can and dose actually use it.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se