From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Mon, 22 Mar 1999 23:36:11 -0800 (PST)

One more GGI3D change, almost there....

	I realized today that the existing GGI3D design has one fatal
flaw: although it supports multiple interfaces, it only supports one
entrypoint (ggi3d_handle_data()).  This means that every other interface
transition must go through ggi3d_command(), which incurs a performance
penalty as the command word has to be examined.  

	Multiple entrypoints are therefore necessary, because penty of
modules will have more than one performance-critical function to perform. 
Some functions are not performance-critical (like getting an ident
string), so those can stay in the command interface.  All this means is
that you have to use CMD_GET_INTERFACE and pass an interface descriptor
struct and you will get back an instance of a generic entrypoint function
int entry(void *in, void *out) for your interface if it exists. 

	The nice thing about this is that I can use helper libraries for
the individual interface implementations, just like LibGGI does!  This
will allow one small(ish) core module to manage a potentially huge number
of different interfaces while still having a small memory footprint.  I'll
be able to encapsulate all possible features of my KGI driver into the
driver's associated visual module.  

	Context binding is also much simpler now.  The visual module
defines the top-level interface set to which all LibGGI3D-using code must
adhere.  It manages all module use and operation within the context of the
visual it encapsulates.  It establishes and manages all rendering
pipelines that terminate in one or more of its interfaces, and it exports
the top-level interface of each pipeline, each in its own separate visual
context.  Any module may be instantiated at will of course, but in order
for that module to be hooked into the display system it must be placed
correctly in a pipeline by the visual module.  Thus, all pipelines are
_guaranteed_ to always operate correctly in the absence of bugs!

	Finally, the ability to export arbitrary interfaces also means we
can have inheritance in the module system.  Now we have a full object
model in LibGGI3D, although you don't have to use it that way.  'Real'
class libraries could easily be built around this facility, however. 

	By the end of this week I should be able to finish the last of the
API changes and release a sample visual object built around LibGGI
primitives.  The crappy existing GGI3D modules will be pipeline-able as I
described above, just to show how it works.  Also, as part of my work I am
building a generic third-party standalone LibGGI3D library development
system, and I should more or less have that ready for release at the end
of the week as well.  Then it's on to writing Mesa support.

Jon

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