From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Sat, 29 Aug 1998 17:02:36 +1000

Re: LibGGI2D, LibGGI3D and targets

Jon writes:

>  	Ok, so a target is a rendering pipeline composed of a set of .dls
>  which implement the API function set and overload each other in whole or
>  in part according to some ruleset.  Sound about right?

Kind of.  The target is like the bottom / tail of the pipeline which
talks to the hardware (like through fbdev or KGI).  It provides the
setmode() function for example.

Then it might load generic-stubs library.  This provide generic drawing,
e.g. a drawhline() methods that calls ggiDrawPixel().  [like the top of
the pipeline].

Then it might load generic-linear-16 library. This provides drawing
tailored to a specific framebuffer type (in this case, 16 bit wide
pixels).  [this one is like the middle of the pipeline].  Imagine for
the moment that this library did not implement the drawhline() method
but only implements drawpixel() method.

Then calling ggiDrawHline() would call generic-stubs's drawhline()
method, which calls ggiDrawPixel(), which calls generic-linear-16's
drawpixel() method, which uses the framebuffer information provided by
the display target to draw a pixel.  Thus a horizontal line gets drawn
(albeit slowly).

Methods like setmode(), drawpixel() & drawhline() exist in the
vis->opXX structures, and libraries can override them when they are
loaded (with explicit code in their GGIdlinit() function).

LibGGI3D, being an extension library, can provide new methods (like
draw3dtriangle) which could be overridden by libggi3d-aware sub-libraries
in the same way.

Hope that helps.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/