From: Rodolphe Ortalo <ortalo@laas.fr>
  To  : ggi-develop@eskimo.com
  Date: Wed, 19 Aug 1998 11:41:28 +0200

RE: 3d

>	I have to admit at this point that I am a bit unclear on the
>difference between a LibGGI-family library (like LibGGI2D or LibGWT) and a
>LibGGI extension library.  I envison LibGGI3D as being quite analogous to
>LibGGI2D.  It would be a true API, have its own extension libraries,
>etc.
>
>Jon

Unless I'm strongly mistaken, libggi2d and libgwt _are_ extension library,
at least in theory.
The reality of the current source code may be a little more complicated,
hence I understand your difficulties... ;-)

libggi2d operates as an extension lib, and registers new functions for
each ggi_visual_t it is attached to (this may be implicit sometimes).
libggi2d also uses some of the dynamic loading/unloading
functions of libggi to load specific display target (such as linear_8,
etc.) But this is "just" to adapt each extension function to the target
(some kind of second step).

libgwt _should_ be an extension library, but is not yet, and won't be
before v.0.0.2. Currently, its functions operates as conventional library
functions, and operate on a gwt_window_t data type (not on ggi_visual_t).
For 0.0.2, we will change that to have real extension functions that
are passed a true ggi visual... (The window data should be hidden behind
it.) [Please, don't comment on that too much, 0.0.2 will be a prototype
implementation. I want to see how this schemata operates...]
Currently, libgwt only has init functions to register as an extension
lib, but doesn't really register new functions (hence, it is an "empty"
ext. lib.)

Note that (at least for 0.0.{1,2}) libgwt will not have multiple display
targets... So you can have an extension lib without specializing on
different bit depths for example. (For libgwt it is probably reasonable.)


For libggi3d, I think the suitable example is libggi2d. However, for pure
extension lib functions (ie: without the additional complexity added to
functions and makefiles by the dynamic loading/unloading of display target)
the best starting point is surely the extension/test/* files, which are
really examples (from Andreas).
You may not need to have different display targets in the first place, unless
you already have specialized functions for various bpp. If you have, take
care to cleanly separate (at least mentally) the different issues, it may
be confusing to adress both things simultaneously (I did that mistake :-).


Anyone, correct me if I'm wrong please... ;-)


Rodolphe