From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Fri, 11 Sep 1998 00:55:58 +1000

Re: SYNC mode should go

Andy writes:

>  I myself do not care, but I am _very_ anxious, that it will hinder acceptance
>  for LibGGI, if we drop it.

Ok.

>  The problem I see is, that people who are accustomed to other graphics APIs,
>  which are inherently synchronous (because they access some framebuffer e.g.),
>  will find using LibGGI a major pain, as they have to drop in all those 
>  "useless" Flush() calls.
....  
>  The point is, that the "innocent" newbie user can hack away without having
>  to learn what ggiFlush() is good for and why it is needed and where it should
>  be put, while it is a matter of a few extra instructions (a SetFlags and a
>  bunch of Flush()es), to set things right lateron.
....
>  I still think, that for "QuickHack"(TM) things, SYNC mode is a nice thing,
>  because you won't forget to put a Flush() before the Getch() or something.

These uses of SYNC mode (newbie hand-holding and prototyping) do not
warrant (a) having SYNC mode the default, and (b) trying to make SYNC
mode effective for targets like X (in my opinion).

Personally I'd like to see SYNC mode removed, the API becomes a little
cleaner but the code becomes a _lot_ cleaner.  But I am not against
retaining a SYNC mode that

   (a) isn't the default, and 

   (b) doesn't even try to optimized it in any way.  If it crawls on X,
       then it crawls on X.  Tough!  It might even encourage people to
       write their programs "the right way".

For (b), I'm talking about doing an "if (SYNC) ggiFlush()" after every
primitive (in libggi/stubs.c) instead of the mansync stuff we have now.
Very basic, but it does the job without all the jumping through hoops
that mansync does.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/