From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Marcus Sundberg <mackan@stacken.kth.se>
  Date: Sat, 3 Jul 1999 12:35:56 -0400 (EDT)

Re: Palette proposal

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.

> > 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.

> 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, but on visuals with GT_STATIC_PALETTE, ggiSetPalette 
always returns -1.  The documented return code for ggiSetPalette
(the first index set) would remain the same when GGI_PALETTE_DONTCARE 
is used.

> 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.

--
Brian