Re: Proper way to provide gtk+ app with asynchronous data?

[Juhana Sadeharju <kouhia nic funet fi>]

>From: "Dmitry M. Shatrov" <zzidre mail ru>
>
[ ... ]

Here is my suggestion: create the thread, which handles the input and
the critical processing, before initializing GTK. Create a separate
process if necessary. This way you don't need enter/leave pairs.

In an audio level meter, I would create a thread for reading the audio
data from the card. The same thread processes the audio and generates
the level information.

The GUI thread would receive the information in a form which is
suitable for displaying. If data is a stream, then the sample rate
of the information must be lower than the display refresh rate,
e.g., 20 times per second. Lock-free fifos are used. If the data is
not a stream, GUI may read periodically the shared memory variables
for information. Some information may be missed (but nothing important
in the example).

The GUI callback may be launched by sending a wake-up byte to a pipe
which is watched by the GUI. The level information is still read
via shared memory.

The time critical audio thread/process may run with soft-realtime
privileges and the GUI may run normally.

 -*-

I have a similar problem: gtkglext has the shapes.c demo. The display
gets slow because my extended shapes.c draws the bunny. The slowness
is ok, but the pop-up menu raises only after the drawing has ended.
More, I want to process motion notify events while the bunny is
drawn. Does the enter/leave pair help here? How I should place
them in the shapes.c? (gtkglext.sourceforge.net)

Juhana