From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 25 Mar 1999 22:25:27 -0800 (PST)

Re: GGPG updated

On Thu, 25 Mar 1999, Brian Julin wrote:

> 
> Some updates to the GGPG.  A chapter on basic hardware access concepts
> in the Hardware Programmers Guide, and a sneak preview of the 
> GGI Extension HOWTO (it still needs a bit of rearrangement as
> to where it assumes extensions will be built, and a little more work 
> is needed on GGIExtensionHelper before I release it.)  Read... 
> Comment...  Contribute.

	Comments, since I am still trying to get my head around the LibGGI
extension concept to make sure that WRT my GGI3D work I am A) using it
properly and B) taking maximum advantage of its potential.  So....

	In all the explanation of what a "visual" is, I didn't see the
word "context" used once.  My impression was that the primary purpose of a
visual was to serve as a unit of context, to which both LibGGI and any
loaded extension libraries would bind arbitrary state info (via the
"private" hook) and additional API functions and their implementations.  I
also thought that targets were just arbitrary sets of API implementations,
not a fundamental representation of the underlying "back-end".  Just a
convenient, flexible way to organize the API implementation code, in other
words.  Is this wrong? 

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

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

	But then I thought, what if all KGI functionality was embodied in
a LibKGI extension, and both the LibGGI and LibGGI3D KGI target code was
just a thin wrapper around that API?  Then we would have all of the
benefits of the existing target system, but I would also be able to access
all of LibKGI's functionality on my own!  And there would be close to zero
code duplication.  Most target code is concerned with implementing API
calls, setup routines (hook API calls, init variables, hook visual
context) and manipulating context in some way.  With an extension, you
just put all the setup code in the ExtInit() call, put the context
manipulation in your new API calls, and put any API extension
functionality in overloaded functions just like the targets do now.

	Another example is Glide.  If I want to access Glide's high-level
drawing functions, I can't use LibGGI because no extension whose API calls
encompass triangle drawing, etc has been written.  But if I use Glide by
itself, I no longer have access to all the nice LibGGI features.  However,
if Glide were implemented as an extension (LibGlide), I would be able to
have the best of both worlds.  I could call every Glide function, handle
all my Glide context info with a LibGGI visual hook, _and_ be able to
accelerate all the LibGGI API calls that the Glide target currently
accelerates!

	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:

LibS3
  LibS3Trio
    LibS3Trio64
      LibS3Trio64V+
    LibS3Virge
      LibS3VirgeDX
  LibS3STREAMS

or:

LibKGI
  LibKGICon
  LibSuidKGI
  LibKGI-core (the "real" in-kernel KGI)
    LibKGI-core-Linux
    LibKGI-core-OpenBSD

or:

LibTele (corresponds to the 'tele' target)
  LibTeleTCP
  LibTeleIPX
  LibTeleCompress
  LibTeleGGI
  LibTeleGGI2D
  LibTeleGGI3D
  LibTeleOpenGL

or even:

LibTranslate
  LibPalemu
  LibTrueemu
    LibTrueEmu-16to8
    LibTrueemu-24to8
      LibTrueemu-24to8-dither
      LibTrueemu-24to8-interpolate


	No more .inc files!!! |->.  All common code is handled cleanly and
separately, and can be loaded and unloaded at runtime.  I am going to
implement a Glide-alike rasterization library for my KGI driver as a
LibGGI extension set as described above.  

	The best part is that this approach will make the task of writing
a LibGGI3D visual module much easier as well!  All the visual module will
have to do is to export a bunch of different interfaces based on the set
of extensions that are attached to the visual it encapsulates.  Nice and
clean, and most of the actual drawing-stuff code can be pulled out into
extensions, leaving only glue logic and interface handling code in the
actual LibGGI3D modules.  LibGGI3D just got even _more_ lightweight!!

	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 |->.  Load the library onto a visual and start calling OpenGL
functions!  And LibMesaGGI's ExtInit() function can load its own extension
libs to overload the OpenGL API functions, too!  Can't get much slicker
than that! 

	Anyway, enough babble.  If anyone sees a flaw in my reasoning,
please tell me now, because I am working on all this stuff already.  But
if anyone should want to, say, write a LibMatrox or a LibS3Virge or
something similar, I would be happy to help write LibMesaGGI support....

Jon

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