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

[Paul Davis <paul linuxaudiosystems com>]

ah, OK. this helps explain why i continue to use g_idle_add() for this
purpose, then :)

actually, to be fair, i don't use g_idle_add() a lot, but rather my
own implementation of the same concept that Glib::Dispatcher
represents.

On 7/9/12, Chris Vine <chris cvine freeserve co uk> wrote:
> On Sun, 8 Jul 2012 21:44:47 -0400
> Paul Davis <paul linuxaudiosystems com> wrote:
>> 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.
>
> Glib::SignalIdle.connect() is not thread safe and should definitely
> not be used for what the OP wants.
>
> Glib::SignalIdle.connect_once() is hoped to be thread safe as of about
> 2 months' ago provided that the slot object does not represent a
> non-static method of a class deriving from sigc::trackable, but I don't
> think that has hit a main release yet. ("Hoped to be" means that I
> don't think anyone has stress tested it yet, but the code was committed
> some 2 months' ago.)
>
> Glib::Dispatcher doesn't use the idle mechanism.  On unix like systems
> it uses a pipe.  On win32 it uses event objects.
>
> Chris
>