From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 26 Aug 1998 23:54:00 -0400 (EDT)

Re: LibGGI2D, LibGGI3D and targets

On Wed, 26 Aug 1998, Jon M. Taylor wrote:

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

Not all of them.  It is "optional" for targets to implement ggiPutBox(), etc.

Those that have framebuffers simply load generic-linear-* to do all drawing
for them.

Those that don't have framebuffers can implement only GGIputpixel_nc
(nc=non-clipping) and GGIgetpixel, but do implement other drawing functions
to get half-decent speed.

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

See lib/libggi2d/doc/TODO.  Just didn't have time, I guess...

> LibGGI2D code not having been fully separated from LibGGI yet? 

As for LibGGI2d being fully separated from LibGGI, no, it never can be fully
separated, since it depends on LibGGI's extension and DL mechanism and drawing
primitives (for generic-stubs-2d).

> 	My point is this: why does LibGGI itself *have* targets?  For that

Because the targets are needed to do at least basic mode management, e.g.
setting a mode in consoles, creating an X window, getting events, etc. 

Other LibGGI sub-libraries like generic-stubs and generic-linear-* are supposed to
provide code common to a number of targets.

> matter, what *is* LibGGI beyond the dynamic library framework?  Do you see
> my point?

LibGGI defines a "standard" API, handles various data structures, extensions
for extending the LibGGI API, but that's it.  Note that "targets",
"sub-libraries", "driver-libraries" are simply artificial distinctions. 
Look at /etc/ggi/libggi.conf, they are all just *.so files implementing the
LibGGI API for different hardware or displays.

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

Should have been clearer there -- I meant generic-stubs-{2,3}d.  2D generic
stubs do belong in LibGGI2D.

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

Yes, in the strictest sense 2D-specific drawing functions are not pulled out
into LibGGI2D.  Do you mean that an innocent ggiDrawPixel(vis,x,y) should be
put out to LibGGI2D?  That would make LibGGI useless.  LibGGI2D is supposed
to be "advanced" 2D functions -- for example, it has polygons, circles,
alpha values.

LibGGI's "2D" (called "opdraw" nowadays) functions (not to be confused with
LibGGI2D) are intended to give programs a *reasonable* *yet* *low-level*
interface to work with. The idea behind LibGGI2D is to fill some of the gaps
of LibGGI without bloating programs that don't want it.

> 	The impression I am getting is one of function duplication between
> LibGGI and LibGGI2D.  Both appear to be implementing 2D drawing stuff.  I

See explanation above.

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

Because visuals (displays) are usually 2D in nature?  For example, the
console framebuffer and XImages. And 3D cards don't really provide 3D, they
just give an illusion of 3D on a 2D surface (i.e. the monitor).  Now, some
displays might not fit this model, but stripping LibGGI down even further is
unreasonable.

> 	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 means you would have to duplicate *all* target functionality for every
extension library, provided that they don't fallback on each other.  And if
they do depend on each other, you'd go back to the same problem of
"the underlying assumptions of library X breaks library Y".

>From a purely abstract view, what you said is the ideal implementation, but
it is impractical.  It's like microkernels -- they are supposed to be
minimal, but you still have to start somewhere.

> That is what I thought the basic idea was.  What am I missing here?

No, LibGGI extensions are actually an afterthought in LibGGI's design.
Extensions were provided because LibGGI's API became limiting.

Does this answer your question?

--
Steve Cheng

email: steve@ggi-project.org
www: <http://shell.ipoline.com/~elmert/>;