Re: [fltk.general] R: Bargraph object with Fl_Group
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
[fltk.general] R: Bargraph object with Fl_Group
So good speaking with you, boys.
Greg wrote:
If the image is assigned to the bargraph's group, then just telling the
bargraph widget to redraw() will do it.
But if the image is assigned to the parent window, then you'll have to tell
the parent window to redraw.
Be sure to use an Fl_Double_Window to prevent flickering during redraws.
This is exactly what I am doing now.
Ian wrote:
So long as the background is drawn by your app, then it is feasible to
composite the bar graphs and etc on top of it.
But: If the background is drawn by some other app, or is otherwise outside
the control of your app windows, then compositing the graphs and so forth on
top becomes Very Tricky.
For now the simplest solution I can imagine is to redraw the whole parent of
my object.
Quite possibly: I think we need to understand more about the nature of
the backgrounds, how they are drawn etc, and from there we can figure
out how to render the graphs on top of them...
Well, there is no window manager ; I have microwindows sitting over the
framebuffer and a single fltk application which does everything, so the
situation is conceptually simple,
because everything is drawn from one single app. Background programs to acquire
remote variables, but only one app writing on lcd.
I manage all the firmware, from bios to Linux kernel to user interface, so I
have full control on the machine.
I am trying to create objects as simple as possible : generally speaking every
object has some functions to animate itself, requesting variables from a
remotely connected machine.
For example:
Think of a plant which, in its full realization, is composed of 4 identical
stations (tanks, motors, etc.) .
For each station the plant supervision designer will put:
- one background image (the drawing of the station) with a visible boolean
coming from remote
- one bargraph (value, min, max, visible boolean)
- one box displaying a numeric value (value, format, visible boolean)
- one multiple-image box representing the run status (off, on, waiting, etc.)
- (image index, visible boolean)
- one start/stop button
- etc. etc.
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.
It's the classic supervision software : as general as possible. Windows
software to visually design the plant -- configuration file -- my embedded
software
to parse it and show / animate objects.
-
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.
Thanks
Lucio
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
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.
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
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] R: Bargraph object with Fl_Group
Ok, ok, it's Friday, need more sleep. Simply forced redraw() of the parent solved the problem. It's a bit inefficient, because if the parent is a big window with many objects I have to redraw everything. Masked by redrawing only when the bargraph value changes, for now. Any way to invalidate to the parent only the bargraph area ? Thanks, regards Lucio Messaggio originale Da: memoryl...@tin.it Data: 15-mar-2013 10.34 A: fltk@easysw.com Ogg: Bargraph object with Fl_Group Hi all, I am trying to create a simple object representing a bargraph. It is a simple filled rectangle, derived in a Fl_Group ; the draw method simply draw two rectangles, one with fill color, the other with background color. All is ok ; now I want to add a transparent background option. I cannot draw the background rectangle, so when the rectangle is growing all is right, but when the bargraph value goes down... How can I force the erasing of the filled rectangle before redrawing it with the new dimension ? Any suggestion is welcome. Thanks all, regards Lucio Dona' ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
Simply forced redraw() of the parent solved the problem. It's a bit inefficient, because if the parent is a big window with many objects I have to redraw everything. Masked by redrawing only when the bargraph value changes, for now. Any way to invalidate to the parent only the bargraph area ? Derive a widget from Fl_Box to draw your graph, and have its handle method do the actual drawing etc. Set the boxtype of your derived widget to a BOX rather than a FRAME type (and certainly NOT to NO_BOX) and then the background should be handled automatically. FL_FLAT_BOX is probably favourite for this sort of thing. Deriving from group is probably a Bad Thing here, since IIRC the default boxtype for a group is NO_BOX, which probably explains the behaviour you are seeing? Indeed, simply setting the boxtype of your group might actually help... 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] R: Bargraph object with Fl_Group
thanks for your answer. I am writing to you directly, Best not - I very seldom reply to off-list posts... will post solutions on list ; for now maybe there is a bit of misunderstanding, I try to explain better. The object is a bargraph, let's assume the classic vertical one ; a green rectangle on a white background. Can derive from Fl_Group or, better as you say, from Fl_Box. The problem comes when I want the white background to be invisible: I would like to see a green rectangle growing or shrinking representing a tank level. If the background is invisible I can place the object over a photo of a plant, for example. OK: Then you need to composite the bar graph on top of the image. Fltk does not provide support for transparent widgets (yet) as it is a hard thing to do in a consistent cross-platform way, so the best bet may be for you to just blit the image into the box, then render the bar on top of it. This is easy and cheap to do, if you are rendering the graph on top of an image your app owns. If you want to render the graph transparently on top of (for example) the desktop then you are on your own out there, since fltk can't really do that without a lot of platform specific code...! Hope that made sense! FWIW, I think Greg's cheat pages have examples of doing some of this, so it would be worth a look... http://www.seriss.com/people/erco/fltk/ 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
