From: Olivier Galibert <galibert@pobox.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 07:29:46 +0200

Re: Can I do that ?

On Thu, Aug 20, 1998 at 10:04:02PM -0700, Jon M. Taylor wrote:
> 	Anyway.  About the 7bit CLUT -> 9+ bit whatever copying, sure you
> could do it.  If you want colorspace translation, write a target to do
> whatever you need and render from the main memory to the memory buffers
> through that translation-target.  Look at the existing trueemu and palemu
> targets to see examples of how this could be done.
> [...]
> 	As far as the transparency goes, either draw through an alpha
> stencil or use a custom transparency target.  And the double-buffering can
> be done by rendering to an offscreen visual and flushing it to the display
> visual (which would probably be a DirectBuffer mapped to the hardware
> framebuffer) every vblank.

I don't understand what it is that you call a target.  Or if I in fact
understand it, I don't see how it can be efficient.


> > If the hardware if appropriate, all of  this should be done within the
> > card, of course.  Otherwise the libggi* will have to emulate all these
> > in main memory, the fastest possible of course[1].
> 
> 	Of course.  Now, you have to realize that "the fastest possible" 
> requires more and more code, specialized targets, KGI drivers, etc to get
> closer to.  But in priciple you should be able to optimize the rendering
> pipeline as finely as you have the time and inclination to do.  With
> LibGGI, all is possible.

Every coder out   there will optimize  the ggi  implementation for his
card anyway.   Did you think  about  making libggi  itself modular the
same way kgi is?

Libggi (and friends) can be seen as a bunch of default implementations
(with probably some generic  programming to have good specialisations)
and hooks for the card specific code (card taken in the generic sense,
i.e.  including X, svgalib  or  aalib).   The so-called  "KGI drivers"
should include in fact two modules, one to be loaded by the kernel and
one  by libggi.  This  would give much more  room for optimization and
experiments in the userspace/kernel communication implementations.

This would of course not preclude from reusing code from one driver to
the other.

  OG.