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
