Re: [fltk.general] Bargraph object with Fl_Group
>> 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. > OK: but my suggestion was that you have groups nested within groups, so that > the redraw's can be localised to just one specific sub-group... Yes, it's right. Now the configuration file is "flat" up to the page level, in the sense that it's divided in pages. On each page I have buttons, images, etc. Each page is a group, and all objects belong to the same group, logically at the same level (Z-order is implicitely handled by the object declaration order ; it's not possible to overlap two animated objects). I could introduce another level of detail, in the sense that the bargraph should be member of a small sub-group, containing the bargraph itself, the background, etc. Maybe this can be handled from the plant installer: Windows configuration software should handle "sub-objects" (recall the example of the station, formed by the bargraph, a background, on button...) . These sub-objects would be the ideal candidates to be in a sub-group, and could be then grouped at configuration-file level. Without this information from the plant installer it's difficult to "generalize" : there could be one *big* tank image, and 5-6 bargraphs over it, each one representing different things (level, temperatures, etc). In this case the group is the whole tank and all the bargraphs... On the other side: small tank, small background, one bargraph - the perfect sub-group. The problem, IMHO, is defining a rule (if any) to generalize grouping of objects. Thanks, regards Lucio ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
> 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. Yes, checking for differences, and only then triggering a redraw, is a useful optimization in most cases. Note that it can also help to limit the refreshes even in that case - e.g. have an Fl_timeout that fires every so often (say 1 Hz) and triggers the redraw based on the latest state, "ignoring" any intermediate inputs... Selex ES 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 fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
> 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. OK: but my suggestion was that you have groups nested within groups, so that the redraw's can be localised to just one specific sub-group... Selex ES 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 fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
Albrecht wrote: > http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2 > to damage a particular region (like invalidateRect would do). It works ! Now forcing a damage to the bargraph parent() passing to it the coordinates to invalidate. Removed, for testing, the previous bargraph value check (to invalidate very often), and the CPU utilization stays low. Reactivated, for good programming, the "previous bargraph value" check. Thanks !! Regards, Lucio ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
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
