From: =?iso-8859-1?Q?Anders_Mod=E9n?= <anders.moden@mailbox.swipnet.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 20:14:11 +0200

RE: new design (Re: LibGGI2D, LibGGI3D and targets)

GREAT ! I Agree... Send me a note and I'll be with you !

> -----Original Message-----
> From: thomas@eskimo.com [mailto:thomas@eskimo.com]On Behalf Of Thomas
> Tanner
> Sent: den 27 augusti 1998 12:36
> To: ggi-develop@eskimo.com
> Subject: new design (Re: LibGGI2D, LibGGI3D and targets)
>
>
> Jon M. Taylor wrote:
>
> > > 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.
>
>  Jon, you're absolutely right. You're having _exactly_ the same thoughts
> like me.
>  I often enough argued for moving all 2D functionality out of libggi
>  (even directbuffer), moving events completely to libgii,
>  extensions having their own context rather than storing their data in
> visuals
>  etc.
>
>  That's why I've written a specification for a new GGI design.
>  Here are some excerpts of the README file and specification,
>  which outline some of the differences to the "official GGI design":
>
> Experimental GGI design
> -----------------------
>
> While the "official" GGI design has to take care of backward
> compatibility this alternative design is completely incompatible with
> the old one and emphasizes consistency, extensibility, flexibility,
> abstraction and modularization. It is an experiment of new ideas and
> might influence the further development of the official GGI libraries.
>
> If you have any comments or want to help me then please contact me.
>
> The lastest specification and snapshot can be obtained from
> http://home.pages.de/~tanner/ggidesign.html
>
> Overview/features:
> ------------------
>
>    general:
>
>           + full multithreading support
>           + support for static linking systems like DOS
>           + error codes
>           + very flexible configuration files
>           + and much more...
>
>    config scheme (thanks to Steffen Seeger):
>
>           + very portable
>           + dependencies
>           + "make" from every directory
>           + easy to understand
>
>    LibGGI:
>
>           + very high abstraction
>           + no drawing functions, only visual managment
>           + real color management
>           + independent extensions
>
>    GGI/FB (framebuffer):
>
>           + fallback API, but not a must
>           + no acceleration
>           + supports also alpha- and Z-buffer
>           + direct access possible but not recommened
>
>    GGI/2D:
>
>           + accelerated 2D functions
>
>    GGI/GL:
>
>           + full OpenGL API
>           + Mesa completely integrated in GGI
>           + multiple contexts
>
>    GGI/Screen and GGI/Printer:
>
>           + visual specific interfaces
>
>    GII (input):
>
>           + independent from GGI
>           + gii_input as event source
>
>
>  No API except the basic GGI interface is guaranteed to be available on
> every visual.
>  An application using GGI usually opens a visual, initializes it through a
> visual
>  specific API and then selects a drawing API. Each drawing API has
>  its own context so that several drawing APIs can be used at the
> same time.
>  However, due to limitiations of today's hardware, the simultaneous use of
> more
>  than one drawing API should be avoided.
>
>  If there's no native driver for a drawing API then it tries to load some
>  fallback-drivers, which emulate it on top of other drawing APIs,
>  eg. GGI/GL on GGI/FB or GGI/2D.
>
>  LIBGGI does not imply that the visual is 2D-ish.
>  A visual is defined as:
>  Any graphical object is abstracted by a ggi_visual. It can be a display,
> printer, bitmap,
>  camera, movie, remote visual etc. i.e.
>  everything that has optical characterics like color, shape,
> transparency,
>  intensity (brightness),  depht/structure, sharpness etc.
>  A visual consists of an [in]finite number of elementary visuals (e.g
> pixels, lines).
>
>  This way you can theoretically even draw on a real 3D object. You would
> only need to
>  have a drawing API for real 3D visuals. GGI/2D, for example,
> could then be
> emulated on it.
>
> > > 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.
>
>  Me, too. I'm just working on a implementation of it
>  and I really don't have any problems with it.
>
> > > 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.
>
>  Exactly.
>
> > > 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.
>
> --
> Thomas Tanner -----------------------------
> email: tanner@gmx.de tanner@ggi-project.org
> web:   http://home.pages.de/~tanner
> cool:  www.ggi-project.org  www.gnustep.org
>
>