Re: Re: gtkmm 3.4.0 (gtk 3.4.2) multithread app graphic deterioration

[Giuseppe Penone <giuspen gmail com>]

Hi Harry, my program has a lot of I/O (user, TTYS, TCP) and many inputs can cause
a consistent update of the GUI, for this reason I opted for accessing the GUI from many threads.
This software is for my company (while all my open source apps in GTK are using python)
and it's not easy at this point to revolution the software which should be tested in
days for the Milan (Italy) underground.
Cheers,
Giuseppe.

On Sun, Jul 8, 2012 at 2:28 AM, <harryhaaren gmail com> wrote:

On , Giuseppe Penone <giuspen gmail com> wrote:
> I'm not very experienced in c++ and gtkmm

Hi Giuseppe! I'm not a Gtkmm wizard, but from my experience its best to leave all graphics drawing calls to one thread.
That thread we will call "main" thread, and its the thread that runs into Gtk::Main::run(), after which your programs UI shows.
All other work ( I don't know what the context is of your program, but lets say its downloading something) should be done in a worker thread. This can signal to the Gtk::Main thread, and perhaps use a Glib::Mutex for serializing data access.

Since you have to serialize all graphics calls anyway (that's what the GDK lock does), there's no point in having different threads doing the graphics: only 1 will run at a time.

I know this was slightly OT, but I found I asked many similar questions to yours when I was starting out with Gtkmm so I hope its relevant... -Harry