Me: > > The question: what is the correct way to fire a graphics update from > a thread ?
Albrecht: > Others will probably chime in and tell you more about programming with > threads and FLTK. Ian: > 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 ! Thanks, regards Lucio _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
