From: mentalg@geocities.com
  To  : ggi-develop@eskimo.com
  Date: Sat, 12 Sep 1998 10:37:53 -0400 (EDT)

Re: Time for a stable version release ?

On Sat, 12 Sep 1998, Andrew Apted wrote:

> I'm tending to agree with what Andy seems to be saying: either we have
> a SYNC mode that is fully "official" and allowed to be used (and with
> reasonable performance), or have none at all. 
> 
> I like Steve's proposal of a "ggiEnableSync()" function that is allowed
> to _fail_ if the target doesn't have SYNC mode behaviour.  Bad programs
> that require it (and die if it isn't available) will be in the same boat
> as bad programs that require DirectBuffer and die if it isn't available.

Yes; that's probably a better idea, except what targets besides SVGALib are
actually totally synchronous?

> >  * To lock or not to lock... ggiLock/ggiUnlock would greatly increase
> >    the performance of libggi and ease implementation of many things,
> >    and I think it's a piece of cake for users to learn it. Many, if not
> >    most, modern gfx API's that provide both acceleration and direct FB
> >    access have lock/unlock calls anyway.
> 
> I like it, but IMO the function names should be more explicit, such as
> ggiLockFramebuffer() and ggiUnlockFramebuffer() which show just what is
> being locked/unlocked.

Good point.  Actually, we need ggiLock() and ggiUnlock() for
locking/unlocking the visual structure itself anyway.

-=MenTaLguY=-