From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 00:33:05 -0700 (PDT)

Re: Can I do that ?

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

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

	Hopefully.

> Did you think  about  making libggi  itself modular the
> same way kgi is?

	?  Did you reverse KGI and LibGGI in that sentence?  If so, yes I at
least have considered this.  But LibGGI depends heavily on the userspace
ELF dynamic library system.  I am not sure how easily the same sort of
thing could be done in the kernel.  If it could be done, it would probably
be a good idea.

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

	It is important to distinguish between the LibGGI-family APIs and
their targets.  The *targets* are the implementations.  But yes, you are
in essence correct. 

> The so-called  "KGI drivers"
> should include in fact two modules, one to be loaded by the kernel and
> one  by libggi.  

	Kernel modules cannot be loaded without root privileges.  If you
ran part of LibGGI as root daemon, it could maybe do something like this. 
This starts to look like Linus' "superserver" concept.

> This  would give much more  room for optimization and
> experiments in the userspace/kernel communication implementations.

	Yes, it would.  I do not recall ever hearing about a dynamic,
polymorphic, virtual method based OS.  The closest analogy I can think of
are the class libraries that virtual machine languages like Java and
Smalltalk are based on.  Anyone know how much of this stuff can be done
today with Linux modules? 

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed