> So the job of auto-update would lie within Image::put. It
> sounds like a
> very bad idea to call check() every time in such a tight loop, and my
> typical use case would in fact be very similar, 100% CPU bound. The
> solution I found was to keep a counter, decrease it on each call of
> put(), call redraw() whenever it hits 0, and then reset it to some
> positive value computed so that the refresh occurs at the appropriate
> frequency. The assumption being that put() will be called at regular
> intervals. Like this :
That's an OK approach - fltk does not care if you call Fl::run() or not,
so long as you contrive to call Fl::check() or Fl::wait() every now and
then instead.
How often "every now and then" is can be pretty subjective but 10Hz
would probably kick it for most practical purposes (though faster is
smoother...)
> It does work well, but I have the feeling that it is a bit
> cobbled up in
> a non-optimal way. What would be a better design ? Maybe spawning a
> thread for the display (though I seem to remember reading that display
> was only allowed to be done in the main thread) ?
If it were me, I would use another thread for this; for robustness, the
GUI portion would be in the main thread, and would call Fl::run().
Prior entering the fltk run-loop (or perhaps from a callback) I'd spawn
a worker thread that would do all the actual computation, so the main
thread would be basically idle, just keeping the GUI alive.
I'd also do Fl::add_timeout() and that would tick away checking the
output of the worker thread and updating the display when appropriate -
the idea being that the worker thread probably doesn't know anything at
all about fltk or even the display, it just dumps it's data into some
output store from which the timer callback retrieves it for display.
> The one thing I want to avoid is "while (check()) { compute(); }"
> because I would like the emphasis to be on the (non-interactive)
> computation itself, the display being very secondary - plus it would
> require storing some additional state, defining compute() in a
> reasonable way, which would be nice enough to return early,
> ... I dont't
> mind for the definition of Image to be complicated, but main() should
> really be as simple as shown above.
Yup - sounds fine. That's pretty much what I described, I think.
Don't be confused that the GUI thread is not "secondary" to the real
work, simply because we have to place it in the main thread. For our
purposes here, the only thing that is special about the main thread (on
those platforms where it is special at all) is that it has ready access
to the graphics interface, which worker threads might not have.
If you do thread your code like this, in most cases you will get better
CPU utilisation since the GUI thread, prone to blocks on the display
h/w, is separated from the computational heavy-lifting.
(And threads will usually utilise multi-core CPU's better anyway.)
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
