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

[Paul Davis <paul linuxaudiosystems com>]

the simplest solution is actually to use the GDK idle handler.
whenever you receive data that requires some sort of redraw, you queue
up an idle callback that will call someWidget.queue_draw() and then
returns false (so that it is not called again). i tend to do this with
C (g_idle_add()) rather than C++ but IIRC the syntax is something
like:

    Glib::SignalIdle().connect (sigc::ptr_fun (&somethingThatWillQueueARedraw));

or

    Glib::SignalIdle.connect (sigc::mem_fun (&some_object,
&Object::someMethod));

Glib::Dispatcher is a more general purpose mechanism that is actually
built on the idle mechanism if i recall correctly.

On 7/8/12, Giuseppe Penone <giuspen gmail com> wrote:
> I'm quite interested in what you say
>
> In another posting you said your program does a lot of input-output.
>> You don't need threads just for that: you can set up a watch on a
>> file descriptor for the main GUI thread using
>> Glib::signal_io().connect(). GIO/giomm also has a wide range of
>> asynchronous IO functions where all the hard work is done for you.
>>
>
>  even if I made something like this (I've always dedicated a thread to
> every different input), consider that anyway I need the gui thread not to
> be blocked when the input is
> receiving large amounts of data.
> I will do research following your tips, thank you.
> Cheers,
> Giuseppe.
>