Index: [thread] [date] [subject] [author]
  From: MenTaLguY <mentalg@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 1 Jul 1998 20:10:29 -0400 (EDT)

Re: Removing SYNC mode

On Wed, 1 Jul 1998, Andrew Apted wrote:

> Hi folks,
> 
> I'd like to propose that we remove SYNC and ASYNC modes/flags from
> LibGGI, with the following justification :
> 
> 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?

>  The only LibGGI targets that natively have
> this behaviour is those which draw directly to the hardware (KGI, fbdev,
> svgalib, XDGA afaik).  All other targets must emulate it, and this is a
> royal PITA.
> 
> 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.

Keep accelerators in mind here; even if you have direct access to the
framebuffer, you still may be able (and want to) let the accelerators do
their own thing until you're ready to let them catch up with ggiFlush().

Otherwise, you end up waiting around for each individual accel operation to
finish, while you COULD be using the CPU for something useful otherwise...
that IS the point of accelerators, right?

If we take out SYNC and ASYNC modes, we'd damn well better do so in favor
pure ASYNC behavior, which happens to be fast everywhere. :) I mean ... SYNC
mode IS basically there for the sake of old DOS programmers used to broken
synchronous conventions ...

Bleah. I'm in a grumpy mood right now. Probably a bad time to be responding
to this. :/

-=MenTaLguY=-


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