From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Morten Rolland <Morten.Rolland@asker.mail.telia.com>
  Date: Mon, 16 Aug 1999 11:45:45 -0400 (EDT)

Re: Ping-pong buffers on KGIcon are here!

On Mon, 16 Aug 1999, Morten Rolland wrote:
> This method could be made to work very well for applications using
> either accels *xor* writing directly to the framebuffer, but how
> about an application that (accidentially) mixes the two rather
> closely?

That would qualify as a broken application.

> Wouldn't unmapping/faulting/sleeping/remapping involve a rather
> bad performance hit when the batched accels queue is short?

Yes, but the fault only happens when the application tries to
access the directbuffer.  If it's doing it through a LibGGI 
primitive like it should, the sublib is free to check the 
accel_queue_empty GC flag and either sleep or ioctl a flush, 
rather than faulting, and in fact the app code can do this as well.

> Why not require the application (and GGI-lib functions)
> to make a check and sleep if accels may be running still, as
> suggested earlier in this thread?

Unmapping the framebuffer is for broken hardware.  If the locking 
isn't enforced by the kernel, a malicious application can hang the 
system.  If the hardware is not broken there's no reason to unmap
the framebuffer, and the advisory lock method is fine.

> This may require a change in the GGI-API,

GGI already can flush the accel queue and check for accel busy
with the current API (as soon as Marcus's system is all the way 
implemented in the new PP code.)  I don't see what change would be 
necessary -- ??

--
Brian