From: Hartmut Niemann <niemann@cip.e-technik.uni-erlangen.de>
  To  : andreas.beck@ggi-project.org
  Date: Mon, 21 Sep 1998 10:10:57 +0200 (MESZ)

Re: New target `display-tele' committed -- async and sync mode

> 
> Hi !
> 
> 
> This gives horrible performance over high-latency links, except if you
> decide not to give back errors for functions that usually don't fail and
> maybe buffer up requests to reduce latency and transfer overhead.
> 
> CU,Andy
> 
> -- 
> = Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =
> 
> 
I was recently thinking about exactly this.

The way accelleration is planned will have a *BIG* impact on this.
We had the idea of sending commands to the kernel by some means like
ping pong buffers, ioctrls, special files or whatever. The kernel would
feed the accellerator engine with them.

Did you ever notice that this asynchronous mode will not allow any
useful return codes, because the kernel-level checks that need to be
done for e.g. blitting (you may not read kernel memory ...) will not happen
before the function returns, and what good is it if
a line draw some 20 lines after an illigal blit returns with ENOTALLOWED?

So normal accellerated mode will be asynchronous, and all asynchronous
commands *could* fail without even a chance to tell the program.
Libggi could perform those checks the kernel will, but it might
(for some reason) not catch everything. 
So this kind of failure is possible not only over notworks but with a 
high-speed ping-pong buffer accelleration interface.

So for debugging we (IMHO) will need a truly synchronous mode
for all accellerated targets (to be consistent: for all targets) that
guarantees that  a drawing command is executed before the function
call returns. This will be horribly slow on accelleration engines,
but it will be the only choice to catch some bugs.

The key is: the command must be executed to memory. It must not
necessarily be already on the screen.

We might as well be honest enough to make all such commands return
void.
Those commands that return a value (ggiGetBox, getpixel...) will be
checkpoints anyway, and will need all pending accelleration be executed
before the get operation.

On the topic of reordering: What would that be good for?
I would prefer to guarantee that all drawing requests are executed
*in the given order* unless the target is absolutely sure that reordering
has no effect.
If the programmer has to decide what can be reordered and what not,
this will be a nightmare.

Comments?

Hartmut.
--  
Hartmut Niemann   --   niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]