hv wrote:
> On developing a little app with a bunch of charts (about 8+ line
> charts being updated at about 50 hz), I have found a real
> architectural/response issue in FLTK that is kind of a pain.
> So if you stack up a bunch of samples to an Fl_Chart (of line type),
> what happens is that you always redraw the entire lot of samples.
> Each time you do a Fl_Chart::add(..), redraw() is called, which
> is as it should be, but then the /whole/ chart is redrawn instead
> of anything approaching a dirty-rectangle or 'latest data point'
> optimization strategy.
Supplying us with a small app showing how bad it is would help.
How much data is in the chart at any given moment?
Are we talking 10's or 100's or 1000's of chart elements?
Probably it's drawing the whole widget because, I'm guessing,
the existing samples have to get smaller to make room, and
thus the whole widget would have to be redrawn once the
event loop is given control.
When add()ing the data, do you do it in a tight loop,
or do you do it a little at a time, with redraws between
each add()?
If it's slower than 50hz for a reasonable number of samples,
sounds like the code needs optimization.
Fl_Chart does not appear to be intended for real time use,
otherwise it'd use a linked list instead of an array. Looks
like memmove() and realloc() are used whenever a block of
FL_CHART_MAX elements are add()ed (ie. 128 elements).
I haven't looked closely, but FL_CHART_MAX should probably be
user configurable instead of a constant, so that an app that knows
it will be dealing with 1000's of elements can define that to a high
number so that the array is allocated quickly, instead of a little at
a time during the add()s.
If you think Fl_Chart can be used for realtime purposes with a
few tweaks, try just copying its code to your own dir and tweak
to taste. If you get something worth using, feel free to send us
a patch.
> This is just awful. What are the chances I can get a patch for this
> or re-write and submit something with marginally better mechanics?
You're probably best to copy the widget code and tweak it
to taste. I'm pretty sure the dev team isn't going to jump
on rewriting Fl_Chart as a realtime widget without a patch
to start with, or a code example demonstrating the problem.
I have to say when I'm doing real time stuff, I code the
widgets myself using either Fl_Box or the raw fltk box/line
drawing functions so that I know my speed concerns and
data management issues are addressed.
Widget code can change optimization-wise, so its best never
to depend on widget code being highly optimized for realtime
unless the widget is intended for realtime (eg. Fl_Gl_Window)
> This is slowing the hell down on my little graph collection app.
> FLTK is otherwise fast to develop with and runs kind of OK, but man,
> this is a real weakness when dealing with these charts and X overhead
> and drawing management (this is on a Dell Laptop, Ubuntu 8.10,
> using sources from FLTK instead of Ubuntu/synaptic package).
Since add() is implemented to call redraw() on the whole widget,
and not doing a damage() for affected regions, it's going
to draw the whole widget when fltk's event loop retains control.
So it's best to at least add as much data as possible in a single
stroke, without giving cpu to the FLTK event loop during that time
(redraws don't actually happen until the event loop gets cpus.
As you probably know, calls to redraw() just set the damage bit
for the whole widget, but no redrawing is actually done until
the fltk event loop gets some cpu)
Is your app using Fl_Double_Window instead of Fl_Window?
The former will hide any 'flashing' so that updates appear
smooth, assuming speed is not all of the issue.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
