From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 26 Aug 1998 19:56:30 -0700 (PDT)

Re: LibGGI2D, LibGGI3D and targets

On Wed, 26 Aug 1998, Steve Cheng wrote:

> On Wed, 26 Aug 1998, Jon M. Taylor wrote:
> 
> > 	I've been looking at how to start coding some LibGGI3D display
> > targets, and in the course of exploring the existing LibGGI targets I saw
> > that LibGGI2D doesn't have any targets per se.  All the targets are part
> 
> From a cursory look, LibGGI2D has implementations for linear_16, linear_8
> framebuffers, and stubs using ggiPutPixel(), etc.

	Right, but PutBox(), etc. are defined in the LibGGI targets.

> > of LibGGI itself.  Why is this?  IMHO, the targets, to the extent that
> > they handle 2D framebuffer rendering, should be part of LibGGI2D. 
> 
> Yes, _should_. (e.g. to take advantage of hw accel)  

	So will this change at some point?  Is it just a case of the
LibGGI2D code not having been fully separated from LibGGI yet? 

> But it isn't necessary, because it just calls LibGGI targets' stubs, or draw
> on the framebuffer directly if available.

	My point is this: why does LibGGI itself *have* targets?  For that
matter, what *is* LibGGI beyond the dynamic library framework?  Do you see
my point?

> > Otherwise, I either have to go ahead and create separate LibGGI3D display
> > targets (which gives LibGGI2D and LibGGI3D inconsistent structure) or 
> 
> Some time later down the road both LibGGI2D and LibGGI3d would have some
> targets, it just depends on whether you want to implement first (the targets
> or the generic stubs).

	Of course, but don't the generic stubs still belong with the API
that uses them?  They may be generic stubs, but they are _2D_ generic
stubs.
	
> > I
> > have to add LibGGI3D code to the LibGGI targets (which adds bloat
> > unnecessarily).  
> 
> No.

	Good.  I am going to code all LibGGI3D targets separately, then.

> > The demos in lib/libggi/demos all seem to be 2D-oriented
> 
> Well, 2D as in ggiPutPixel(), ggiDrawLine() etc.  They don't actually call
> LibGGI2d's functions.

	Now I am confused again.  I thought that all 2D-specific drawing
functions were pulled out into LibGGI2D.  I thought that was why LibGGI2D
was created.

> > - do they belong in lib/libggi2d/demos?  Please help me understand this.
> 
> lib/libggi2d/demos/demo.c actually uses LibGGI2D.  Different from libggi
> demos.

	The impression I am getting is one of function duplication between
LibGGI and LibGGI2D.  Both appear to be implementing 2D drawing stuff.  I
hope that a clean separation of the two will eventually occur.  I am
worried that the underlying 2D assumptions of this stuff will conflict
with some of the 3D stuff I am going to be doing.  Why should the
oundation of the whole LibGGI system be 2D-specific? 

	IMHO, LibGGI should not have targets or implement drawing
functions.  It should consist only of the dynamic library/
extension/buffer/visual abstraction handling - i.e. the framework only, no
implementation specifics. LibGGI should be the "kernel" of the LibGGI API
system, doing nothing by itself and existing only to provide an
environment on/in which to build other, functional libraries like
LibGGI2D, LibGGI3D, LibGWT, etc.  That is what I thought the basic idea
was.  What am I missing here?

Jon

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