From: teunis <teunis@computersupportcentre.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 10 Sep 1998 17:41:39 -0700 (MST)

Re: SYNC mode should go

On Thu, 10 Sep 1998, Andrew Apted wrote:

> MentalGuy writes:
> 
> >  I've been beating my brains out over the past week or so trying to come up
> >  with a decent thread-friendly locking scheme that would be consistent with
> >  and with USE_THREADS and didn't break the signal implementation of mansync
> >  (or vice versa), and while I sort of worked out an API with both a
> >  signal-friendly intlock/sigmask locking implementation and a pthreads
> >  implementation, it's still a pretty ugly and inconsistent solution.
> >  
> >  Honestly, we should really drop SYNC mode...
> 
> I second that.
> 
> SYNC mode is not something that can easily emulated when the target
> isn't natively sync-ish (like KGI and FBDev are).  
> 
> Like I said before, in all the docs (and demo.c) we strongly recommend
> not using SYNC mode, yet it remains (and as the default too!).
> 
> It definitely should be go IMHO.

Note: for DOS people, DirectBuffer is what they want anyways.   Open a
mem-visual on a directbuffer (can that be done?) and you'll have the same
effect (SYNC mode).  No accels but some people would be happier.

... on most cards accels share with this properly.  Some (S3 805 comes to
mind) aren't as friendly IIRC but I could be wrong.
[there was a card I played with a -long- time ago where you had to run
accels inbetween display writes for things to work - as in don't write to
the screen until you flush()....]

G'day, eh? :)
	- Teunis

PS: I vote with the "take the SYNC out and put it in a toolkit/extension"
crowd.