| Author |
 Topic  |
|
|
slavik
2 Posts |
 Posted - 06 Aug 2006 : 11:41:29
|
Hi forum,
I'm using an RTScrollFrame to display a span of 10 seconds with 4 values being added every 10 milli-seconds (4000 values total viewable points). I don't care about history that is not displayed but I would like to display all viewable (4000) values in a fast 100 millis refresh rate. After a few seconds, the value pushing is getting really, really slow (I'm using setCurrentValue(double, double) when X is the time in millis).
Here is what I'm doing:
1. When creating the RTProcessVar I'm setting:
1.1 curProcessVar.setAutoTruncateDataset(true);
1.2 curProcessVar.setAutoTruncateMaxCount(numberOfDataPoints + numberOfDataPoints / 10);
1.3 curProcessVar.setAutoTruncateMinCount(numberOfDataPoints);
1.4 curProcessVar.setDatasetEnableUpdate(true);
1.5 curProcessVar.setAlarmTransitionEventEnable(true);
2. I'm creating the RTScrollFrame using:
2.1 new RTScrollFrame(this, transform,
ChartConstants.RT_FIXEDEXTENT_MOVINGSTART_AUTOSCROLL)
2.2 scrollFrame
.setScrollScaleModeY(ChartConstants.RT_NO_AUTOSCALE_Y);
2.3 scrollFrame.setScrollRescaleMargin(0.0001);
2.4 scrollFrame.setMaxDisplayHistory(0);
Am I doing somthing wrong?
The problem I'm seeing is that as the underlying TimeSimpleDataset gets bigger, the updates are getting slower.
Please help :-(
10x,
Slavik |
|
|
quinncurtis
1586 Posts |
Posted - 06 Aug 2006 : 12:46:38
|
There is no switch that we can tell you to change that will speed up the display. The scroll frame is not designed for high speed scrolling, because when a redraw is triggered it must redraw every point of the graph. Java is not a language for high speed drawing. Our own tests show that it's maximum line drawing rate is only 10%-20% as fast as .Net, and .Net is only 30-50% as fast as C/C++ code calling directly into the Windows API.
We reiterate throughout the software that you should make the update of the data asynchronous with the display, that is what all of our examples do - because the update of the data has virtually no overhead, and the display update has tremendous overhead. You should use two timers, one at 100 msec for your data update and a 1 second timer for your display update. When the display updates you will see all of the data collected at the 100 msec interval.
We designed the software this way because we decided that ultimately, fast incremental scrolling is of very little practical value, and mostly has only aesthetic value. Better to allow the data to update 100s of times a second, while displaying all of the data at a slower update rate, in a stable, artifact free graph, with associated axes, grids, labels, annoations, etc.
|
 |
|
|
slavik
2 Posts |
Posted - 07 Aug 2006 : 02:51:15
|
Hi guys,
First of all, thank you very much for the prompt response.
I was not expecting any /makeItFaster switch :-).
I'm using a timer for the refresh and a separate thread for the pushing of data so this was not my problem. I was looking for a way to limit the display from redrawing what it did not need (ala setFastClipMode(FASTCLIP_X)) and limiting the history using setAutoTruncateDataset(). But, your answer made me think about the refresh rate for our display. We did all our checks with a refresh rate of 100 millis (10 times a second) which turned out to be too much. After setting the refresh rate to 200 millis or less, the graph behaves much better. Thanks a lot for the answer.
10x,
Slavik |
|
|
| |
Topic |
|
|
|
Very slow RTScrollFrame display
