>> 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 c
> 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
> 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 h
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 pre
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 th
5 matches
Mail list logo
