On 16 Mar 2013, at 06:28, [email protected] wrote:
>
> Now a plant is smaller and has only two stations: the remote machine will put
> some "visible" booleans to zero... and the graphics app
> will show only the installed stations.
>
> So one can think: I create a group with image, bargraph, boxes and it's done.
>
> I can't do this, because my app has to be general: it's the plant installer
> who knows how the plant is made.
> He will create the configuration file for my app (we created a Windows
> software for this), specifying where (x, y) and how big the objects are.
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...
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!
>
> Coming back to the problem: instead of redrawing all the bargraph parent,
> IMHO the key point could be the ability to "invalidate" only one small
> portion of the parent,
> the rectangular portion under the bargraph.
>
> Bargraph::RedrawObject()
> {
> parent()->invalidateRect(xBar, yBar, wBar, hBar);
> redraw();
> }
>
> First instruction tells the parent to redraw only the part under the
> bargraph, and the second redraws the bargraph.
> Obviously this is general: all objects needing some sort of transparency
> should behave this way.
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!
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
