> > This is because it runs in SYNC mode, i.e. it assumes that there is an
> > automatic flush. There are helpers (mansync) available that will take
> > care for regular flushing in sync mode.
> Interesting. Could you write a little summary of those things ?
O.K. Here we go:
ASYNC/SYNC mode from the user's perspective:
see "man ggiSetFlags".
ASYNC/SYNC mode from the LibGGI hacker's perspective:
SYNC mode is there, because many programmers are used to inherently
synchronous operation like with SVGAlib. Thus and to allow to bridge
such code via wrapper libraries, LibGGI defaults to come up in SYNC
mode.
The user is encouraged to usually set ASYNC mode to allow for better control
of what and when to flush. However there are reasons for staying in SYNC
mode:
If you draw lots of irregular patterns (like random lines) and want them to
be updated from time to time, but do not want to take the burden of doing
such timing stuff yourself.
Flushing at every change would hurt performance badly, as e.g. the X target
would have to redraw a pretty large part of the bitmap it holds for a single
line. Flushing every n-th line would help a lot, but is very dependent on
the hardware speed. The best solution for this situation is to flush every n
milliseconds, giving a constant framerate. However this is very tricky to
program and would probably scare away users.
O.K. - so much to why SYNC mode is there.
There are targets that are inherently synchronous, like fbdev. They write to
video RAM while the drawing function executes and results become visible as
some as the video logic starts to access these updated cells, i.e. at least
at the next refresh of the display. There is nothing to do for those on the
programmer's side. ggiFlush and ggiFlushRegion are noops there.
Other targets, especially those potentially operating over high latency
links or capable of handling multiple output windows at once try to buffer
drawing operations and only execute at ggiFlush()-time.
This is of course much more efficient for these targets.
However, for the reasons given above, LibGGI supports SYNC mode, and thus
targets have to "emulate" it when they cannot do it natively.
The usual way to do this, is to use the mansync helper. You can find it's
source in display/mansync .
It is basically an external thread or process (depending on what is
available on the current platform), that will trigger a ggiFlush every
x ms and thus makes an ASYNC target look like if it were SYNC. The x
can be set by choosing an appropriate GGI_MANSYNC_FPS.
How to use the mansync helper is described in the file
libggi/include/ggi/display/mansync.h .
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
