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.
It's difficult to tell what the rectangle would be. In fact, there is no
such rectangle, if you are in "shift mode", i.e. you add entries after
you have reached the maximum no. of entries, or if you have set
autosize() on. Or if the chart is a pie chart, or ...
> 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?
> 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).
>
> Please advise. Thanks.
First, as written before, please post to fltk.general, but anyway here's
my suggestion:
Your rate of 50 Hz is too high for human beings to follow anyway, but if
you can't (or don't want to) lower the sampling rate because of the
number of points you want to show, then you should separate sampling and
display (redraw) with different timers. However, this wouldn't work
easily, because add() calls redraw() for you.
To omit this, you can do something like this (sort of a hack, but should
work):
int damage = chart->damage(); // save damage bits
// modify chart ...
chart->clear_damage(damage); // reset damage bits
You should also mark the chart as changed then. This can be done best,
if you derive your own class from Fl_Chart, but can also be done in some
private status info.
Then, in your display, timer, you can simply do
if (chart[i] is changed) { // pseudo code
chart[1]->redraw(); // redraw this chart
// reset chart[i] changed status.
}
To test this, use a long display timer (e.g. every 5 seconds), and see
what happens. If done correctly, this should not prevent redrawing on
window resizing, i.e. you should see the chart update, if you resize the
window _or_ when the display timer expires.
Another way would be to gather the samples in local storage and do
widget updates only in the display timer callback (every 1/25th of a
second, as Matthias suggested). This ensures that the draw() method is
called only once per timer event for all charts together.
Albrecht
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
