From: Tristan Wibberley <bloater@ps.cus.umist.ac.uk>
  To  : ggi-develop@eskimo.com
  Date: Wed, 18 Aug 1999 03:04:16 +0100

Re: Ping-pong buffers on KGIcon are here!

On Wed, Aug 18, 1999 at 02:00:02AM +0200, Andreas Beck wrote:
> > > The app now tries to lock down a directbuffer. The same as above happens.
> > > It waits on the accel lock, engages the fb lock, frees the accel lock.
> > > It draws some stuff on the DB.
> > > While doing so, it calls a LibGGI primitive with the DB still locked.
> 
> > It is essential for Glide and (future) DirectX operation that this
> > (calling GGI primitives while a DB is acquired) is not allowed.
> 
> Why ? At worst, we'd just auto-free the fb for the time the ggi primitive
> request is executing. Note, that the reaction that follows in the
> description I gave above, is equivalent to a DB-release, call accel,
> DB-acquire, due to the synchronous accel operation it induces.

Can't the accel just be queued until the DB is released. This screws up
the display, but that is expected when mixing DB and accel anyway.
This could be much faster for crappy hardware than lots of
mapping/unmapping and syncronous accels.

Or do I misunderstand the process you are describing?

> I am thinking about compatibility here, when wrapper libs (SVGAlib might
> be a candidate for that) don't have that restriction.

How can SVGAlib possibly specify that accels happen inbetween DB access?
DB access happens when you write to the mmapped frame buffer without
SVGAlibs intervention (The only reason KGI can do better is because it
has kernel help isn't it?).

Or do I not understand SVGAlib?

-- 
Tristan Wibberley