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

Re: Can I do that ?

On Fri, Aug 21, 1998 at 12:33:05AM -0700, Jon M. Taylor wrote:
> On Fri, 21 Aug 1998, Olivier Galibert wrote:
> 
> > 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.  
> 
> 	A target is a set of drawing functions, designed to render in a
> specific way, which when loaded overload the stock LibGGI drawing
> functions for a particular visual.  So, when I load the KGI display target
> onto a visual, the KGI target's DrawX() functions are used.  If I load the
> trueemu target, the DrawX() functions render to a 32bpp framebuffer which
> is then dithered to 8bpp(?) before being rendered to the final target.
> 
> 	Think virtual methods in C++.
> 
> > Or if I in fact
> > understand it, 
> 
> 	Did you?  Do you now? |->
> 
> > I don't see how it can be efficient.
> 
> 	It is as efficient as the target code.  The functions are
> overloaded at the symbol table level, so there is no additional
> indirection and hence no additional execution cost.  Of course, if you
> chain targets together things will slow down, but you'd have to run the
> equivalent code anyway so.... 

[Sorry, I don't really see what I could trim]

Then I did understand, and it  will be slow.  Or  the API is much more
clever than I thought.

For instance, let's say that I want to send a 8bpp picture to my 24bpp
screen on a matrox millenium II.  You seem to mean that I have to:

1- Send it (I did not found the  appropriate function) to a palemu:kgi
visual

2- bitblt it to the my previously open visual associated to the screen

right?

But  the matrox ILOAD operation  is  able to combine  the blitting and
table lookup in  hardware.  How can the userspace  part of the  matrox
driver shortcut this two-step operation?

Same goes for transparent operations.


> >  Did you think  about making libggi itself modular  the > same way
> kgi is?  ?  Did you reverse KGI and LibGGI in that sentence?

No.   I looked better  at the source  since then (I  don't use KGI for
now), what I was thinking about is already there.  So forget it :-)

  OG.