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
http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
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.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
