Index: [thread] [date] [subject] [author]
  From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Thu, 2 Jul 1998 08:22:43 +0200 (MET DST)

Re: Removing SYNC mode

Hi !


> > SYNC mode means "the drawing operation is guaranteed to be visible
> > within a reasonable time".
> 
> Doesn't it mean, rather, that the drawing operation is guaranteed to be
> visible by the time the appropriate function returns?

You cannot actually guarantee that. Remember, that even if the function has
stopped drawing to video memory, it will take from a few microseconds to
the time needed to display a whole frame (i.e. vert refresh rate) to
actually make it visible.

This is the reasoning for the definition above. It also fits asynchronous
protocols like X, where you can assume that your drawing requst will be
done "real soon", but eventually not be completed at function return.

> > My idea is that when DirectBuffer is available, it implies SYNC mode.
> > When it is not available, it implies ASYNC mode.  Old DOS programs will
> > expect a DirectBuffer, so doing (quick) ports won't be any harder.
> 
> Uh, no thanks.
> 
> DirectBuffer in SYNC mode is still slow; people need to be allowed to use
> ASYNC mode if they want to.

Yes. I think ASYNC mode should always be available. At worst it doesn't
differ from SYNC.

SYNC mode can always be faked using a thread/process that issues a ggiFlush()
from time to time.

So we should always provide both methods, but strongly suggest AYNC mode, 
because it is always faster.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

Index: [thread] [date] [subject] [author]