Re: Real Time Drawing

[John Cupitt <jcupitt gmail com>]

On Wed, 16 Mar 2005 09:14:38 +0000, Athanasios Anastasiou
<thanos atmail com> wrote:
> After some directions from Liam (see yesterdays mailing archive) i
> passed my app through valgrind and found out that there are too many
> errors happening in the GTK / X level. I suppose that it has something
> to do with the way i am using the thread library in combination with GTK.

There are two ways to do threads in GTK:

1) do threads_init, then put threads_enter/threads_leave around
*every* gtk/gdk call which could be called from more than one thread.
There's a FAQ about this approach:

http://gtk.org/faq/#AEN482

2) have a single GUI thread (ie. all gtk/gdk calls are from one
thread), then background worker threads can trigger callbacks in the
main thread to ask it to do work on their behalf via g_source_*()

On pros and cons, (1) is painful and error prone, IMO, and very hard
to use for large apps. Whereas (2) keeps threads separate with well
defined synchronisation points. As I said, (2) works for me on a large
(>100,000 lines of C) GTK program.

> I refrained from using the callback mechanism ( as you suggest) because
> whatever code is executed within there should execute in a time shorter
> than the "packet length".

Hmm, I guess it depends how much work the consumer needs to do. If
it's several ms of CPU per packet, I guess you will need a separate
thread for this. I'd still recommend keeping the GUI single-threaded
and having workers wake it with GAsyncQueue. You could have your
producer/consumer threads communicating with your list, then the
consumer sending "please queue a redraw" messages to the GUI down the
GAsyncQueue.

> You are talking about a GAsyncQueue, now thats something i havent looked
> at. Another thing i havent looked at is threads in glib....I suspect
> that a lot of bad things occur when my "processing" thread tries to draw
> the signal on the widget because at some point i discovered that the
> thread lags and blocks (mind you there is nothing else in the processing
> thread except the plot code)

That sounds bad. You must only plot in the "expose" handler, things
will break otherwise (maybe I misunderstand). glib threads are a very
simple portability wrapper over the win32 and posix thread libraries,
there's no magic there.

> event handler handles the rest...... (And the question now arrises, what
> happens if an expose event from the app collides with an expose event
> that had to be sent because the user minimized and maximized the
> application???)

GTK has a complicated thing that handles this for you. All exposes,
whatever their cause,  go through the single "expose" handler in a
sensible way.

J