From: Thomas Tanner <tanner@gmx.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 21:01:24 +0200

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

Marcus Sundberg wrote:

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

 Yes, I totally agree with this goal.

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

 OK. Although porting the drivers is easy, the system being very stable 
 (it just lacks some drivers) and writing a compatibility libggi-1.4-wrapper
 would be quite simple, I want to clarify something:

 This new design is NOT intended to replace the current libGGI, 
 but a playground for my ideas. People being not happy with the 
 current design or realizing the limitations and waeknesses of
 the current design may have a look at it and might comment on it.
  
 It might influence the development of the official libGGI and
 may someday even merge with it. 

 I do NOT want to throw away our current libGGI. 

 I think it is quite good, runs on many targets and it's 
 sufficient for simple drawing. 
 But I think it could be much better and so I'm trying out some ideas.

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

 Yes. I also think that we should release a stable version of libGGI that
 is able to draw on fbdev, X11 and SVGALib.

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

 Please do not forget that both designs _TRY_ to achieve this goal,
 but there will be certainly cases in which this is impossible or
 does not make sense.

> (Example:
>  + fallback API, but not a must

 I just want to emphasize that we shouldn't rely on something 
 that is not absolutely necessary.
 This is the theoretical difference between these two designs,
 while in practice both try to emulate a framebuffer.

>  Also I don't get this at all:
>  + direct access possible but not recommened
>  why???)

 Just because the lower the level an application accesses the hardware
 the more it depends on it. A program using hardware dependent 
 features like splitline risks that it does not run on all visuals.
  
> * 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)

 I don't want to split the GGI project at all. 
 This is not a split, this is just a personal experiment of some ideas.
 
-- 
Thomas Tanner -----------------------------
email: tanner@gmx.de tanner@ggi-project.org
web:   http://home.pages.de/~tanner
cool:  www.ggi-project.org  www.gnustep.org