From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 16:30:01 +0200

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

Thomas Tanner wrote:
> 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":

[snip]

I'm not saying that you're system is bad, actually I think it's
quite good. But you're forgetting one important thing:
The _main_ purpose of GGI has always been to provide safe,
non-suid, hardware accelerated graphics for Linux, and any other
system that wishes to use the KGI drivers.

The problem is that it'll take time to write drivers and make the
system stable. And when that's finally done we still have to 
convince application developers to port their apps to a completely
new API.

That's where libggi came into the picture. By having a small,
simple to use library which not only would run on KGI, but also
run on all the existing graphic targets on Linux, the hope was
that we could easily convince application developers to write
for this library instead of writing different versions for X,
SVGAlib and XFree86 DGA.

The reason this hope hasn't come true yet is simple: libggi
has been constantly changing, didn't have a defined API with
userdocumentation from the beginning, hasn't been as stable
as one wants a graphics library to be, and lacked important
things like real double buffering.

But now we've fixed the weird quirks that were in libggi,
most of the API is clearly defined (with some small things still
pending), and docs are being written. And as soon as Andy gets
back and we have agreed on all API issues we'll start ironing
out all the bugs.

Also, Linux 2.2 will be released any month now, and it will bring
fbcon to the masses. If we have libggi ready and running well on
fbcon by then there's a big chance that people will start using
coding for libggi.

If on the other hand we scrap the current design and start working
on a completely new one, the first thing that'll happen is
probably that someone writes a SVGAlib driver for fbcon, people
will continue to use SVGAlib, and we'll be stuck with that ugly
piece of a hack forever. :-(

For me it's VERY important that we get a stable release of libggi
out really soon now, and I certainly don't think scrapping the 
current code will help any of the GGI project's goals.
Especially as there're some points in your new design that I find
completely incompatible with the libggi philosophy: every 
application should run everywhere, without changing the source
and on the same architecture/OS - without recompilation.
(Example:
 + fallback API, but not a must
 Also I don't get this at all:
 + direct access possible but not recommened
 why???)

Also remember that libggi is NOT and never was intended to be
an advanced 2D/3D library. The single goal of libggi is to replace
SVGAlib, XFree86 DGA and XPutImage() for game/demo/multimedia
applications. If someone want's more functionality they have
two options:
Write a library that plugs into the libggi extension mechanism -
or write a library that doesn't.

And given that neither libggi2d or libggi3d are ready or have any
applications using them, there's nothing stopping you from
choosing the last option. Libggi, libggi2d and libggi3d have so
fundamentally different functionality that the gain of using
libggi as the base for the latter two is not very big.

To summarise:
* Libggi's purpose is to provide simple framebuffer access
  and keyboard/mouse handling.
* The important thing for the GGI-Project right now is that we get
  a stable version of libggi out as fast as possible. I doubt that
  either libggi2d or libggi3d will reach version 1.0 in 1998 (even
  if I'd be very happy if you proved me wrong), so they really
  don't have much to do with this goal.
* If you don't like the libggi design, feel free to implement
  another library core to use for libggi2d and libggi3d. They
  provide completely different functionality from libggi so
  there's no conflict here.

* MOST IMPORTANT OF ALL: Don't split the GGI-Project. We all have
  the same long-term goal - to provide a good way to do all kinds
  of graphics under UNIX, and other systems as well. Just because
  we don't want the same thing doesn't mean we can't cooperate.
  (If you think I'm overreacting here, you're probably right ;)
   but I'd just hate to see a split because we couldn't agree on
   something, and I wanted to get this said before it's too late)

//Marcus
--
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se