From: mentalg@geocities.com
  To  : ggi-develop@eskimo.com
  Date: Mon, 14 Sep 1998 17:55:28 -0400 (EDT)

Re: Time for a stable version release ?

On Mon, 14 Sep 1998, Marcus Sundberg wrote:

> mentalg@geocities.com wrote:
> > 
> > On Sun, 13 Sep 1998, Marcus Sundberg wrote:
> > > Why should we bloat libggi with this??
> > > Libggi is not a high-level gfx API. We should make sure that
> > > calling drawingprimitives, setpalette and such functions from
> > > different threds work, but that's it.
> > > Things like the above, synchronising modesetting between threads
> > > etc. belongs either in the app or in a higher level API.
> > 
> > The locks Andy describes are an integral part of thread safety, as well as
> > being useful for what he describes.  In the case of indirect framebuffers
> > (i.e. X), it also provides the library with an idea when it should flush
> > that to the display when the directbuffer is unlocked.
> 
> Yes, I know that. But the question I'm asking is if there's any
> need to lock a _framebuffer_ for threadsafety. I perfectly understand
> the need for locks in drawing primitives which may be accessing
> accel registers and other things that may be fscked up by writing
> to them in the wrong order.

well, the idea of framebuffer locks is basically more like refcounting
framebuffers, so once the framebuffer is 'released', it can be flushed to
the underlying graphics junk if it's an indirect framebuffer like in X or
something.

-=MenTaLguY=-