From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Wed, 26 Aug 1998 11:29:00 -0400 (EDT)

Re: Some things that seem to be missing

On Wed, 26 Aug 1998, Olivier Galibert wrote:

> I'm reading  the new documentation   and  some useful  functionalities
> seems to be missing:

> - creating an "related" visual.  This means creating a visual in a new
>   display but on  the same graphic device  that a given visual.  Under
>   X,  it  would open a new  window,  under KGI  it  would create a new
>   virtual terminal, etc...  One on the targets is to be able to have a
>   GUI application (under XGGI/Berlin/whatever) that opens a fullscreen
>   visual in  a  new  mode.  Useful  for  games,  slide   shows, public
>   interactive systems with touch-screens...

Simply open the same "display string" again.

> - the pixel storing order of rectangles should not be specified.  This
>   may prevent in  some   cases to use   hardware acceleration  for  no
>   particular gain.

I recall there is some flag for packed get/but buffers.  Naturally this
would be the order that the hardware wants.  By default, it is not packed to
provide a simpler interface to the application.

> - the library  is not thread safe.   This is bad  bad bad bad  bad bad
>   bad.   This is going back  5-10 years in  time.  It makes code using
>   active threaded components a tremendous PITA to handle.  It probably
>   makes gwt next to useless for anything but X.   Oh, and did I say it
>   is bad?

Yes, I agree it's a sticky problem.
Here's what I've been thinking:

In the targets, driver libraries, etc., do _ggiLock() and _ggiUnlock().

We don't do it in stubs because e.g. in ggiEventPoll() you might want to
release the lock for periods of time.  It might also depend on the target:
e.g. Xlib must lock, but simultaneous drawing on framebuffer should be ok.

ggiFlush should do a _ggiTryLock(), since that is the current behaviour
(albeit X locks on ints!), but the real problem is that pthread_mutex_t
isn't async signal safe, so if we do a _ggiLock() from mansync, we get
a deadlock.

Comments?

--
Steve Cheng

email: steve@ggi-project.org
www: <http://shell.ipoline.com/~elmert/>;