On 16.03.2013 09:24, Ian MacArthur wrote:

> On 16 Mar 2013, at 06:28, memoryl...@tin.it 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.

And so would I. The visibility property could make an entire group
visible (show()) or invisible (hide()).

> The redraw would then be sent to the group, hopefully that would work...!

I assume it would - however, the group would need a solid background,
e.g. one of the BOX types, probably FL_FLAT_BOX.

> With judicious use of groups, you can possibly arrange for some of the 
> widgets to be in another group to reduce the redrawing somewhat...

Just as I wrote above? One group for _one_ image, bargraph, and whatever
else is needed for one station.


>> 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...

This ought to be doable with damage(), but could indeed be a little
tricky to do it right. redraw() implicitly sets FL_DAMAGE_ALL in any
widget, but here you'd have to set FL_DAMAGE_CHILD for the parent
group and redraw() for the widget to be drawn or something like this


to damage a particular region (like invalidateRect would do).

So, it CAN be done, but ...

> If the update rate is low, it is probably not worth the extra effort - just 
> redrawing the lot will be simpler!

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.


fltk mailing list

Reply via email to