When a 'burst' of a few points (say 1000 points) is added (say every 100 milliseconds) to a graph of many points (say almost 1,000,000 points) over a long time period (in this case 100 seconds) using FastLine>AddXY(), and then the graph is cleared and plotting started all over again, I found that the plotting was VERY CPU INTENSIVE primarily because of the allocation/deallocation/reallocation/deallocation of memory that takes place during the continual graph plotting/clearing/plotting/clearing.
I subsequently found that just using DynamicArrays with the Repaint() mechanism DOES NOT WORK because towards the end of the graph, adding and plotting 1000 points requires adding 1000 points to the DyanmicArrays, but REPAINTING almost 1,000,000 points rather than only the REQUIRED NEW 1000 points is VERY CPU INTENSIVE!!!
In order to stop this wasteful allocation/deallocation/reallocation/deallocation there are two things that could be done to decrease the MASSIVE CPU USAGE:
1) Stop the continuous allocation/deallocation/reallocation/deallocation of memory that goes with using FastLineSeries>Add_XY()
I found that there is a Capacity of a "TeEngine" that could be changed for Lists (e.g.):
"TeeDefaultCapacity Unit TeEngine
Description: This variable determines the number of points that the Series will preallocate when adding points. This number is used to resize the internal arrays. The concept is similar to Borland's TList "Capacity" property, but used with arrays and the SetLength method. Setting a high value (for example one million), will preallocate memory space for one million points, so, when adding lots of points, there will not be time spent allocating memory until one million points have been added."
But this does work for TFastLineSeries or TLineSeries (I tried putting in this code but it was rejected by the compiler, C++ Builder 6, TeeChart Pro 6)
FastLineSeries1>Capacity = 1000000; // ERROR, Capacity is not a member of TFastLineSeries
LineSeries1>Capacity = 1000000; // ERROR, Capacity is not a member of TLineSeries
Could changing the Capacity of a FastLineSeries be used to change the amount of preallocated memory for a FastLineSeries so that the wasteful allocation/deallocation/reallocation/deallocation cycle does not have to occur?
2) A possibly easier solution would be to use DynamicArrays, but have a 'RepaintNew()' method to plot/paint ONLY those new points added to the DynamicArrays after the last plot/paint has occurrred.
COULD YOU PLEASE IMPLEMENT AT LEAST ONE OF THESE SOLUTIONS!
Thanks,
Bill
Improving speed of plotting bursts of points in large graph

 Newbie
 Posts: 6
 Joined: Wed Jul 02, 2003 4:00 am
Bill,
Are you scrolling old points off the chart when the new ones are added (and keeping the number of points on the chart constant) or adding the new ones onto the existing one (and increasing the number of points on the chart) ? In either case, the X axis positions of the existing points will change (shift to the left) and thus the pixel location changes and the entire chart has to be redrawn.
1,000,000 points means approximately 1000 points per pixel. The problem with trying to speed things up by only plotting one of those 1000 points at each pixel is of course that the min/max range over those 1000 points will not be shown. I have attempted to get around this by using a series with high/low capability (Candle ?) and found some speedup, but did find that time was needed to compute the min/max range over each 1000 point subregion of the overall data. I did use normal line series that plotted every point and overlayed this high/low series and saw very little difference indicating that this approach was visually correct.
Steve
Are you scrolling old points off the chart when the new ones are added (and keeping the number of points on the chart constant) or adding the new ones onto the existing one (and increasing the number of points on the chart) ? In either case, the X axis positions of the existing points will change (shift to the left) and thus the pixel location changes and the entire chart has to be redrawn.
1,000,000 points means approximately 1000 points per pixel. The problem with trying to speed things up by only plotting one of those 1000 points at each pixel is of course that the min/max range over those 1000 points will not be shown. I have attempted to get around this by using a series with high/low capability (Candle ?) and found some speedup, but did find that time was needed to compute the min/max range over each 1000 point subregion of the overall data. I did use normal line series that plotted every point and overlayed this high/low series and saw very little difference indicating that this approach was visually correct.
Steve

 Newbie
 Posts: 6
 Joined: Wed Jul 02, 2003 4:00 am
Improving speed of plotting bursts of points in large graph
Hi Steve,
I am NOT scrolling, but adding the new points to the right of the existing ones until the right end of the graph is reached (say at 1,000,000 points), then CLEARING the graph, bringing the number of points down to ZERO, and then starting to add points again at the left end. Then repeating this many times. This is what causes the allocation/deallocation/reallocation/reallocation of memory. The duration (length) of the X axis remains the same.
Therefore, the X axis positions of the existing points DON'T change and the entire chart SHOULDN'T have to be redrawn.
I actually wouldnt mind plotting 1000 points over 1 or 2 x pixels and therefore plot the max/min values at the 1 or 2 x pixel locations.
If Steema doesnt implement either of my above suggestions, I guess I'll have to do my own max/min point calculations and plot only the max/min points (I actually tried this, but so far it didnt work out so well  my max/min plotting wasnt the same as the all points plotting).
I'll also think about using the high/low capability of the Candle plot, but I'm not sure that will help much.
Thanks,
Bill
I am NOT scrolling, but adding the new points to the right of the existing ones until the right end of the graph is reached (say at 1,000,000 points), then CLEARING the graph, bringing the number of points down to ZERO, and then starting to add points again at the left end. Then repeating this many times. This is what causes the allocation/deallocation/reallocation/reallocation of memory. The duration (length) of the X axis remains the same.
Therefore, the X axis positions of the existing points DON'T change and the entire chart SHOULDN'T have to be redrawn.
I actually wouldnt mind plotting 1000 points over 1 or 2 x pixels and therefore plot the max/min values at the 1 or 2 x pixel locations.
If Steema doesnt implement either of my above suggestions, I guess I'll have to do my own max/min point calculations and plot only the max/min points (I actually tried this, but so far it didnt work out so well  my max/min plotting wasnt the same as the all points plotting).
I'll also think about using the high/low capability of the Candle plot, but I'm not sure that will help much.
Thanks,
Bill