From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Fri, 26 Mar 1999 20:07:18 +0100 (MET)

Re: GGPG updated

Hi !> 

> 	All through the document, I saw a basic viewpoint put forward -
> that extension APIs should be 'generic'.  That is, they should be like
> LibGGI2D, which implements abstract drawing ops that can be applied to any
> target, accelerated or not.  I think this is too limiting.  Even for
> special-purpose "driver libraries" like hardware-specific rasterization
> libraries, there is a great deal of benefit to be gained by implementing
> the library as a LibGGI extension.  

Well the emphasis is correct, as this is what should be done, _if possible_.

If for some reason it is not feasible to have software fallback, it should
still be implemented in a way, that allows to extend the library accordingly
for other cards/targets that migt offer the same functionality.

> You still can overload LibGGI
> functions, so the basic function of a 'target' can be fully preserved, you
> can hook your own context info into the visual struct, and you can _also_
> extend the LibGGI API, which a target cannot do.  In fact, an extension
> appears to me to be a proper superset of a target.

Not exactly. An extension can usually not on its own create a new target,
but only extend its abilities.

> 	I feel that currently, a great deal of the functionality of many
> of the existing targets would be better implemented as extensions.  This
> point was brought home to me earlier this week, when I wanted to talk to
> my KGI driver outside of the scope of what the existing KGI target or the
> fbdev KGI helperlib could provide.  Those targets are clearly oriented
> around implementing the LibGGI API, rather than providing a generic
> userspace library for KGI access, which is what I was (and still am)
> after. 

There is the "command-hook" for the simple case. We can add more ways to
communicate with a KGI driver as needed.

> I was faced with the choice of either duplicating a lot of the 
> target code in LibGGI3D or hacking direct-to-target passthroughs into 
> LibGGI and its targets.  Yuck.

That shouldn't be needed. You can route your calls to the card through the
generic LibGGI target. if you need additional hooks for that, just modify
the target, as it will benefit other drivers and extensions as well.

> 	LibLinuxConsole, LibX11, LibKGI, LibJonsKGIDriver, LibS3, LibS3Virge,
> LibMatroxKGI, LibMatroxFBDev... pretty much any special-case code can be 
> separated from generic API code and put into extensions libs.  And the 
> division into general-case and special-case libraries can be infinitely 
> fine-grained, for example:

Ahem - we should not overdo the library stuff. Though it might be
conceptually nice, note, that we are already stressing the dynamic linkers
quite a bit. If we add a big bunch of more libs to be loaded, we might
pretty certainly break it.

> LibS3
>   LibS3Trio
>     LibS3Trio64
>       LibS3Trio64V+
>     LibS3Virge
>       LibS3VirgeDX
>   LibS3STREAMS

This is something I'd do with _rendering libs_ (like linear-*).

> Also related to this, I have contacted the Mesa folks about
> getting write privileges to their CVS tree so I can fix up the GGIMesa
> code.  I am planning on turning GGIMesa into LibMesaGGI, the extension
> library |->.

It actually already is. MesaGGI was the first LibGGI extension at all :-).

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =