From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 12 Aug 1998 12:34:35 +0200

Re: LibGGI colormapping

> The colormapping inside of LibGGI has always been dodgy, and now's a
> great time to clean that up.  [BTW, I was rather surprised to see
> default/linear-*/color.c vanish right before my eyes :)]

So you had to surprise me back with this, right? ;-)

> date: 1998/08/12 08:08:34;  author: ajapted;  state: dead;  lines: +0 -0
> Removed fillscreen.c files -- they were either 1) broken (WRT stride) or
> 2) no faster than using DrawBox()

You should have looked closer at those files.
I know the 24-bit one was pretty braindead, but that should have been
fixed, not removed. And the others handled stride 100% correct,
and the 16-bit one was more than twice as fast as DrawBox().

So, how do I get an old file back from CVS?

> Here's the plan:  The ggi_visual structure has a "ggi_color *palette"
> field which is non-NULL for GT_PALETTE modes, and contains the current
> palette.  
> 
> Then, we have a "generic-color" sub-library which implements
> ggiMapColor() and ggiUnmapPixel() for GT_PALETTE modes (using
> vis->palette) and GT_TRUECOLOR modes (using vis->pixelformat) and
> GT_GREYSCALE modes (using a simple formula).  It also implements
> ggiPackColors() and ggiUnpackPixels().
> 
> Although this could be done in generic-stubs, separating the color
> mapping stuff from the drawing stuff is cleaner IMHO,  We could even
> rename "generic-stubs" to "generic-draw" ... that would be nice.

Sounds very good. The palette field could be used by the ramdac
library to store it's palette too.
We should probably have some "altered range" fields too, like the
X-targets do, so that targets can see when the palette has been
changed, and what entries have been changed.

//Marcus