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

[Chris Vine <chris cvine freeserve co uk>]

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