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

Re: LibGGI2D, LibGGI3D and targets

On Wed, 26 Aug 1998, Steve Cheng wrote:

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

	I understand this part.
 
> > > > 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 

	I didn't mean *completely* separated.  I guess I should have said
that |->.  Obviously LibGGI-family libraries have to have *something* in
common.... 

> and drawing
> primitives (for generic-stubs-2d).

	I still don't see why this is done (see below).
 
> > 	My point is this: why does LibGGI itself *have* targets?  For that
> 
> Because the targets are needed to do at least basic mode management, 

	I understand this.

> e.g.
> setting a mode in consoles, 

	Sure.  But that mode does not necessarily imply 2D-ness does it?  
What if someone wants to run Linux consoles on some future 3D holotank 
display and 2D never enters into the picture at all?

> creating an X window, 

	That is specific to a particular 2D target.

> getting events, etc. 

	That I can see.  Events are a totally independent item.  Of course
it can be argued that events should have their *own* library.  I thought
that was what LibGII was for, but people are saying that LibGII is DOA. 
Anyway, how do I write a Glide LibGGI3D display target with the current
system, given that there is already a LibGGI Glide target that does event
handling?  Do I copy the event handling code to the LibGGI3D target (my
best guess right now)?  If so, that's a code duplication that should be
avoidable.  If the input handling was in a separate LibGGI, nothing else
would have to worry about it. 

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

	I see.  But there is a problem with that: it breaks the
encapsulation of the various LibGGI library APIs.  If I want to render 3D
triangles to a 2D framebuffer, I will use a LibGGI2D display target. 
LibGGI3D will not be concerned with rendering lines in 16bpp (which is the
type of thing those sub-libraries are there for, no?).  I will just tell
the LibGGI2D target to render some lines.  Specifics of 2D buffer layouts
and 2D drawing commands are not part of LibGGI3D.  Ergo, I will not be
using those sub-libraries in LibGGI3D.
 
> > 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.

	Right.  So why is there any common *.so shared code aside from
Event handling stuff?  It makes sense to me that, since the *.so
extensions are by design tied to specific API functions, that they should
be tied to specific APIs like LibGGI[2,3]D or LibGWT.

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

	That's my point.  Almost all of that code *is* 2D generic stubs. 
That is why I was wondering why it was all separated from 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 is exactly what I mean.  A pixel is a 2D object.

> That would make LibGGI useless.  

	By itself, yes, except maybe for the input stuff.  Again, I
thought that was the idea.  I thought that LibGGI would handle the "glue" 
code - the concept of a visual with context, the generic API extension
handling, the DirectBuffer stuff, and other such common, foundational
code.  If this is *not* the case (which appears to be true), I would like
to advocate that it become so.  Maybe not right now, but someday.  See
below for more on why I think this is a good idea. 

> LibGGI2D is supposed
> to be "advanced" 2D functions -- for example, it has polygons, circles,
> alpha values.

	I thought it was to handle *ALL* 2D stuff of any kind.  If you
want to separate low-level 2D stuff like basic framebuffering, the concept
of a pixel, clipping, etc from the higher-level LibGGI2D stuff (arcs,
polygons, alpha, etc), I would advocate having a LibGGI2D-basic and a
LibGGI2D-advanced or some such similar thing.  That is how I am planning
on laying out the GGI 3D stuff.  At the bottom will be LibGGI3D, which
just draws shaded triangles in 3space.  Above that will be
"LibGGI3Dworld", which will handle more abstract shapes, higher-level
clipping, higher-level shading, etc. 

	The idea of multilevel APIs is quite sound.  However, I disagree
with the idea that the core LibGGI should have primitives in it.  IMHO it
should be independent of any particular representational scheme or
function set.  It is cleaner and it facilitiates API "nesting" which
promotes code reuse and is flexible and powerful. 

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

	Reasonable only if you assume 2D-ness underlies all displays.  
That may be true in practice, but A) it is not *universally* true and B) 
it is going to get less true as time goes by.

> The idea behind LibGGI2D is to fill some of the gaps
> of LibGGI without bloating programs that don't want it.

	I understand now.  I don't agree with the reasoning, but I
understand.

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

	That is going to change bigtime RSN.  If LibGGI3D renders to a
VRML target, is that 2d?  Is a z-buffer 2D?  Is an OpenGL world 2D?  I
realize that most of these 3D representational systems *end up* being
rendered to 2D, but not always!  Soon we will have true 3D displays which
never do 2D at all.

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

	Internally, many 3D cards model true 3D worldspaces.  So does
VRML.  So does Renderman.  So does OpenGL. 

> Now, some
> displays might not fit this model, but stripping LibGGI down even further is
> unreasonable.

	Why?  What would be hurt by pulling the remaining 2D stuff out of
LibGGI and placing it with LibGGI2D?  Everyone would have to target their
apps to LibGGI2D instead of LibGGI, but is that a big deal? 
 
> > 	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.  

	They *would* "fall back" on each other.  See my LibGGI2D target
for LibGGI3D idea above.  It makes perfect sense.

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

	They wouldn't *depend* on each other, just *use* each other as
rendering targets.  LibGGI2D will be just one of many LibGGI3D rendering
targets.  If LibGGI2D's API has to change, the LibGGI3D LibGGI2D display
target must be updated.  So?  You have that possibility with *any* target
API.  If the fbdev API changes, the fbdev target will need some work.  The
fact that LibGGI2D is a LibGGI-family library makes zero difference to
LibGGI3D.  It is just another display target.

> From a purely abstract view, what you said is the ideal implementation, but
> it is impractical.  

	I don't see why this is the case.

> It's like microkernels -- they are supposed to be
> minimal, but you still have to start somewhere.

	Right, and that is why a core LibGGI should remain.  But the
current situation is like the WinNT microkernel, which M$ shoved the video
drivers into unnaturally.  Pull the video drivers back out of the NT
kernel and you still have a small, focused microkernel that doesn't make
assumptions about the nature of the device drivers.

	Same goes for LibGGI.  2D is just another representational scheme. 
The fact that it predominates today does not mean that it is special. 
IMHO.  The microkernel analogy is quite appropriate. 
 
> > 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.

	I understand.  But the extension architecture does allow us the 
chance to modularize and layer the whole LibGGI API family much more 
sensibly and cleanly than was possible before.  I am just suggesting that 
we take the process to its logical conclusion.

> Does this answer your question?

	Yes.  Thank you.  Let me assure you that I am not advocating
ripping the guts out of LibGGI right now.  I am not necessarily advocating
making *any* changes right now, aside from what stuff the LibGGI2D TO-DO
file suggests.  But I would like people to think about what I have
written.

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