Re: Queue Draw does not always call expose signal

[Simon Jenkins <simonj2 gmail com>]

Thanks Chris, that was the problem. After giving me that direction, I looked around, read a little and figured it out. 

For anyone else having this problem, I found the following resource very useful: http://tadeboro.blogspot.com/2009/06/multi-threaded-gtk-applications.html

The solution was simply to do:
        gdk_threads_enter();
        parent->queue_draw();
        gdk_threads_leave();

In hindsight, I would have designed things a little bit differently to allow the code to be easily ported to Windows.

Thanks again Chris, you're a real life saver.

Simon

On Sun, May 1, 2011 at 5:04 AM, Chris Vine <chris cvine freeserve co uk> wrote:

On Sat, 30 Apr 2011 18:37:34 +1000
Simon Jenkins <simonj2 gmail com> wrote:
> Hi There,
>
> I'm almost done creating an application using Gtkmm, which has a
> drawing area (an OpenGL scene), which serves as a soon to be open
> sourced graph visualisation application. A big thank you to all the
> creators for this tool, but I'd like to ask for some help :)
>
> The program is event driven, but has a thread running that processes
> the layout. Every time one iteration of the layout algorithm in the
> layout thread has occured, I call 'queue_draw()' on the drawing area.
> The drawing area has the following definition:

[snip]

> I would greatly appreciate any suggestions.

If you are calling queue_draw() in the layout thread, you should
note that GTK+ is not thread safe unless you are also using a unix-like
environment and lock and unlock the gdk global lock (the global lock
cannot be used with windows). libsigc++ employs no locking and so is
also not thread safe unless you employ external synchronisation (and
because of the design, sigc::trackable is extremely difficult to use
safely).

Chris