> > The question: what is the correct way to fire a graphics update from
> a thread ?

> Others will probably chime in and tell you more about programming with
> threads and FLTK.

> Ah... That quite possibly means me then...

> Firstly, a caveat: Rendering to the display device from any thread other than 
> the "main" thread is not robust (may work on some systems, will fail in 
> horrible, hard to debug ways, on others, so do not do that.)
I can confirm this. REALLY horrible ways.

> Instead, all drawing is done from the "main" thread. In particular, note that 
> creating/deleting/hiding/showing windows *has* to be done by the "main" 
> thread.
> However, if you create your widgets in the "main" thread, you can alter them 
> from other threads quite safely, if you use the fltk locking methods. You can 
> signal updates between threads using Fl::awake(); there's no need to get 
> fancy with pipe's > and so forth (fltk is handling that internally) and it is 
> more portable.
>Here's a simple recipe for this:
>- in the "main" thread, before you create any windows, call Fl::lock(); *just 
>once* to enable thread support. (Do not do any more locking/unlocking in the 
>main thread, let fltk manage that for you.)
>- in a worker thread, if you want to update a widget, do:
>   Fl::lock();
>   my_widget->change_this();
>   my_other_widget->change_that(value);
>   etc.;
>   Fl::unlock();
>   Fl::awake();
>And that should update the widgets in a thread-safe way, then flag the main 
>thread to manage the redraw sequence.

In my first app I used Fl::lock, but when the app is growing I have to be 
careful not to create deadlocks, as threads can communicate with each other.
Nothing impossible, but I found the "pipe" method a little easier to debug.

> Note that Fl::awake can also be passed a callback function - the "main" 
> thread will then execute that callback in its context, 
> allowing the worker threads to do some operations that would not otherwise be 
> allowed 
> (e.g. you may be able to use this to create new windows under the control of 
> a child thread, since the actual creation will occur in the context of the 
> "main" thread.)

This is interesting. I missed it.

> However, that is often not necessary, the simple case I outlined above covers 
> a lot of use cases.

Albrecht and Ian, thank you for your help.
If you are coming to Italy let me know, beer ready for you !



fltk mailing list

Reply via email to