From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sat, 12 Sep 1998 14:39:54 +0200 (MEST)

Re: Open list of issues before Degas goes out

Hi !

> > * Licensing issues
> I though that was settled.

O.K. - what was the settlement ?

> I have done most of this. Its at my web site.
> http://www.afterfive.com/~jsimmons/linux-kgi.tgz. I believe I have
> directions on my web page.

Oh - good ...

> IMHO. Remove SYNC and place it in a extensions library. 

I should really stop this talk about putting SYNC mode somewher in an
extension or a target or ... .

SYNC mode is not just another LibGGI call. If it is there, you need to
take care of it in _EVERY_ target that isn't inherently synchronous.
You need to take care of proper locking.
You can't just have some extension that spawns off a thread calling
ggiFlush(). On asynchronous targets, you will be in serious trouble, if
no proper locking is done.

And you need real asynchronous behaviour for ggiFlush() to emulate the
behaviour of a synchrnous target. Just doing something like setting
a flush_needed flag (like Linux setting need_resched) and testing it in
LibGGI calls won't cut it, as e.g. ggiPuts("My question ?");select(..);
would break as the system is in a blocking select() and no LibGGI function
gets called, though the question isn't yet displayed.

Regarding the argument of code bloat:

There are two things that are a bit hairy about the SYNC-hack code:

1. The signal handling and/or thread stuff. This is taken care of by 
   the mansync system. Sure using up a signal is bad, but it is the best
   we can do.
2. The locking. Proper locking needs to be done, so that asynchronous
   calling of ggiFlush will not cause problems.
   Actually I think it is a good thing to have proper locking. It might
   help tremendously, if we decide to make LibGGI _really_ threadsafe,
   i.e. to be able to draw from multiple threads simultaneously.
   I think this should be possible and not cause a application to segfault
   or something, because it gets a conflict with its backend.

There are only two options :

1. keep it as is - eventually changing defaults to start out with ASYNC.
2. remove it entirely, eventually using a stupid hack like
   #define ggiSyncDrawPrimitive do { ggiDrawPrimitive();ggiFlush(); }while(0)
   to regain Sync mode.

Either one is o.k. with me. But don't remove it and say "Yeah, and then
some day we will build an extension to make up for it.". That won't work.
Alternatively you can prove me wrong and implement this extension right
away.

> default. ASYNC is better. Yes Xlib works by ASYNC. Also being a X windows
> programmer there is a specail call that can force Xlib into SYNC mode.
> This is only to debug programs. Its nice to see when a error occurs in
> your program. In ASYNC mode you can't tell when the error occured.

X sync mode and GGI sync mode are _VERY_ different animals. X sync mode
is effectively {ggiDrawSth();ggiFlush;}. This crawls. Think of someone
drawing pixel-by-pixel.

GGI sync modes flushes at reasonable intervals, to keep the user updated.

The best example I think is say a raytracer or some other thing that
calculates a picture. 

If we had no sync mode, we would have three options for flushing:

1. At the end of the frame. No wasted cycles, but the user doesn't get 
updated.
2. at regular intervals (pixel-wise), i.e. every line or every pixel.
This wastes cycles, if the calculation runs fairly quick compared to
the calculation
3. Check at every pixel, if a certain amount of time has passed since the
last flush and flush in that case. That is rather optimal, but a bit
complicated.

SYNC mode is effectively 3. Without any complication. 
To do away with the two most annoying things about the mansync hack, we
could just introduce an envvar GGI_MANSYNC="SIGNAL_TO_USE[:frames/sec]".

> I just hate suser their. Could we put suser in fbcon-kgi.c and pass 

I'd just add some "checkpriv()" call to the KGI API which will get mapped to
system-specific priviledge checking mechanism.

DOS would return 1, Linux probably suser(), someone else might want to
return (user==graphicsmanager) ...

CU,Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =