Hi all,
thanks for the observations.
Ian wrote:
I *think* what I'd do is create a group (probably with a FLAT_BOX type) that
contained just the required widgets - I'd populate this at runtime with
widgets as required based on reading the config file.
The redraw would then be sent to the group, hopefully that would work...!
With judicious use of groups, you can possibly arrange for some of the
widgets to be in another group to reduce the redrawing somewhat...
The parser of the configuration file recognizes the page keyword. Each page
is a group, which in turn contains all the objects to be visible in a screen:
- buttons to go to other screens
- static images (background, etc.)
- animated images (run/stop/pause images)
- bargraphs
- edit boxes
- etc.
Each whole page is a group-derived object ; I keep a list of pointers to these
objects and jumping to another page is easy.
Just make the current group invisible and make visible another.
The redraw() caused by the bargraph goes to the current visible page group ;
a typical plant can have 20-30 different pages.
The main and only window is a Fl_Double_Window.
What sort of update rate are you looking for?
If the rate is slow, then redrawing the whole lot, in a double_buffered
window, will be smooth and relatively painless.
Will depend on how powerful your device is of course, but if it is plant
control, then animating at a few Hz may be fast enough,
without taking too much resource away from other tasks?
Humans can't actually respond to inputs much faster anyway, so refreshing at
more than a 2 or 3 FPS is just wasting cycles
- we are not making a movie or a video game here, so we don't need 60 FPS to
make things work!
Right. Refresh rate is very slow, no need to run faster than 2-3 FPS.
You can manage this by controlling the damage regions for your widgets - but
you still need to do the redrawing of the damaged regions yourself, the
toolkit will not do it for you...
If the update rate is low, it is probably not worth the extra effort - just
redrawing the lot will be simpler!
Now bargraph sends redraw() to the parent (the page group) and it works.
Messages from the plant data driver can arrive at different rates (say from 200
ms up, depending on what is written in the config file) ;
if I fire a redraw() each time I receive the bargraph level my CPU utilization
for the graphics app goes from 4-5% to 60%,
so I simply redraw() when the new bargraph value is different from the previous.
Albrecht wrote:
http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
to damage a particular region (like invalidateRect would do).
... I missed it, thanks !!
Agreed 100% ! Don't optimize prematurely. It's much easier and saves a lot of
trouble and testing to (re)draw entire groups, unless you
(the OP) really need(s) it.
Agree with you.
Let's say that for now I resolved with groups. I still have to keep an eye on
not firing too many redraw() calls, but this is part of the
normal way of programming.
Will have a look at the particular damage() call.
Observations / suggestions are welcome.
Thanks,
best regards
Lucio
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
