From: Tristan Wibberley <bloater@ps.cus.umist.ac.uk>
  To  : ggi-develop@eskimo.com
  Date: Thu, 18 Mar 1999 12:23:28 +0000

Re: LibGGI3D -> LibGGI 3D extension RFC

On Wed, Mar 17, 1999 at 08:06:01PM -0800, Jon M. Taylor wrote:
> 
> 	I have chosen to implement this capability by allowing for one unique
> module to be hooked to the visual context by GGI3D.  This one particular
> 'visual module' will encapsulate the base features of the visual.  When it
> comes time to flush the visual, this module is what will be hooked into an
> overloaded ggiFlush() function. All other modules attached to the visual will
> exist solely to process and feed datastreams into the visual module.  If the
> behavior/layout/whatever of the visual module can change (for example, when a
> different KGI driver is used with the genkgi fbdev helper), the visual module
> will export a set of interface datasets, each of which corresponds to a
> possible permutation of the nature of the underlying visual.  LibGGI
> extensions or sub-modules or targets or whatever may be made use of inside
> the visual module to implement these various possible functional differences.

You mean you make your module pipeline, and libGGI3D provides optimised
code from a driver lib for that visual to replace the bottom chunk of
your pipeline? This is great, it takes out some of the complexities of
putting together a fast pipeline - now you can pretty much just say
"draw me a sphere", and it does, quickly. Or do I misunderstand.

> 	Visual modules will be able to manage the operation of any rendering
> pipelines (pipeline modules) associated with their visuals.  This means that
> the user can construct complex pipelines out of modules attached to the
> visual and have the whole rendering process kick off when ggiFlush() is
> called on that visual.  Fully automatic rendering with the ability to tweak
> the pipeline layout as much as you want at runtime!  And systems like GLX
> and/or Precision Insight's multipipe direct rendering infrastructure will be
> snap to implement - just have the visual module multiplex several pipelines,
> one per thread, each one with a head module attached to an OpenGL/Mesa
> context encapsulation module.  Or a Direct3D encapsulation, or Xlib, or
> LibGGI for multihead-on-a-cube |->.

--
Tristan Wibberley