T(Fast)LineSeries performance issue on Android

[Leo_]

Hi,

I think I'm experiencing a serious issue with the TLineSeries/TFastLineSeries running on Android.
Using Delphi 10.2 Upd 2 and Steema TChart V2016.19.161025.

I've put together, and attached, a stripped down multi device demo project demonstrating the issue.

What I'm trying to achieve is the following:
- Running graph (yes still ) receiving 22 data samples per sec = Update Chart approx every 40 millisec (1s = 1000ms -> 1000/22 ~ 45ms)
- Display up to 2 minutes of data = 22 * 60 = 1320 point in Series, but hold up to 1 hour (79200 data samples).

In my demo project a separate thread feeds the chart (Main thread) every 40ms with a random datavalue [0..100]
In the Main thread (or application); datavalue is consumed, chart scrolled accordingly, and a label*** is updated to show the performance of the thread.
***The label is updated with number of milliseconds since the chart (In main thread) was last updated. The expected value would be 40 ms.

Running my multi device demo app on Windows: The Value is, as expected, 40ms. I can even add thousands of more samples to the series, and the app still performs just fine, updating at 40 ms.
BUT; doing the same on Android (same code of course); the app can only handle about 500 (!!!) data samples before the performance decreases noticeably. At a 1000 data samples the chart will only manage to be updated (draw/scrolled/data added) every 70ms. And it just gets worse as more points are added.
At 2000 data samples it's every 110 ms
At 5000 data samples it's every 230 ms
At 10000 data samples it's every 400 ms (!!!!)

I was hoping it was my coding that caused the issues I'm having, but after a lot of testing and debugging I think it's TChart. Please tell me if I'm wrong
I really hope you have time to address this as it is a showstopper for the release of our software. ....and you know, It's me they're "beating"

Other than that the app is coming along great and could not have done with out it.

Thanks in advance

Regards,
Leo

[Leo_]

Just noticed that an updated version of TChart was available.
I have now upgraded and tested with the latest version V2017.20.170306 and the reported is issue is still present unfortunately.

Regards,
Leo

[Yeray]

Hello,

Setting DrawAllPoints to false should help here. The problem is that with this simple application it doesn't seem to help because when you change the TSpinBox value you are doing a FillSampleValues. You are doing it for testing purposes but the XValues are incremented daily and you are scrolling the bottom axis considering milliseconds. This works a bit better:

Code: Select all

procedure TfrmMain.spValuesToKeepChange(Sender: TObject);
var i: Integer;
    aValue: Double;
    tmpNow: TDateTime;
begin
  //Just add some random points to series so that we do not have to wait for it .....
  //Just for demo purpose
  if SeriesLiveTracking.Count < trunc(spValuesToKeep.Value) then begin
    tmpNow:=IncMilliSecond(Now,-trunc(spValuesToKeep.Value)*AddAndScrollSleepTime);
    chMain.BeginUpdate;
    for i :=0 to trunc(spValuesToKeep.Value)-1 do begin
      aValue := aValue + RandomRange(-10, 10);
      aValue := Max(0, aValue); //Prevent values less than 0
      aValue := Min(100, aValue);
      tmpNow:=IncMilliSecond(tmpNow,AddAndScrollSleepTime);
      SeriesLiveTracking.AddXY(tmpNow, aValue);
    end;
    chMain.EndUpdate;
  end;
end;

We aren't at those 40ms, but at least the time needed to draw the chart doesn't grow and grow with the number of points.

[Leo_]

Hi,

1. Setting DrawAllPoint for this situation could seem like an improvement, but it's not. It might improve drawing speed as (I guess) it draws fewer elements, but the way it draws it (when also scrolling) is absolutely not the way to go. The graph gets very shaky.

2. I'm not sure what you mean whey saying: ".....but the XValues are incremented daily" ? I'm not "incrementing" anything daily?

3. I think you might have misunderstood the purpose of the SpinBox in my demo. It was just there to add points so we did not have to wait for the
"real procedure" to do it. Skip the SpinBox and let the app itself add the points for some minutes, and you WILL see the decrease in performance.

4. Please don't get me wrong, but your statement: ".....at least the time needed to draw the chart doesn't grow and grow with the number of points." is just simply wrong. Bear in mind the after pressing the SpinBox the number of points are static, thus the performance (draw per ms) is also static.

Can I please ask to you have another look at this? I've attached a new demo without the SpinBox. Let the app run until it has added 5000 samples. You WILL see the performance decrease from
(device dependent) drawing every 40 ms to drawing every approx 240 ms. That is 6 times slower for just 5000 points!
To have a graph scroll smoothly, it's seems it needs to be able to draw at least every 70 ms (just an observation).

Regards,
Leo

[Yeray]

Hello Leo,

1. Setting DrawAllPoint for this situation could seem like an improvement, but it's not. It might improve drawing speed as (I guess) it draws fewer elements, but the way it draws it (when also scrolling) is absolutely not the way to go. The graph gets very shaky.

The algorithm avoids drawing the points that coincide in x pixel position with a previously drawn point. However, when scrolling these collisions vary and so do the points being actually drawn, causing this strange effect you noticed.

2. I'm not sure what you mean whey saying: ".....but the XValues are incremented daily" ? I'm not "incrementing" anything daily?

You were, at least indirectly. Note FillSampleValues calls Add function, and this function adds values in sequential XValues (0,1,2,...); and the difference between 0 and 1 in TDateTimes is one day.

3. I think you might have misunderstood the purpose of the SpinBox in my demo. It was just there to add points so we did not have to wait for the
"real procedure" to do it. Skip the SpinBox and let the app itself add the points for some minutes, and you WILL see the decrease in performance.

Adding points with an X increment of one day - through FillSampleValues - and scrolling the bottom axis considering the increment was of 40ms was giving a strange effect.

4. Please don't get me wrong, but your statement: ".....at least the time needed to draw the chart doesn't grow and grow with the number of points." is just simply wrong. Bear in mind the after pressing the SpinBox the number of points are static, thus the performance (draw per ms) is also static.

I thought the spinbox was supposed to be pressed while adding points. Otherwise, how were you verifying the performance?

Can I please ask to you have another look at this?

Sure!

I've attached a new demo without the SpinBox. Let the app run until it has added 5000 samples. You WILL see the performance decrease from
(device dependent) drawing every 40 ms to drawing every approx 240 ms. That is 6 times slower for just 5000 points!
To have a graph scroll smoothly, it's seems it needs to be able to draw at least every 70 ms (just an observation).

I see you aren't removing points in this version of the test application. Apparently, points out of the screen are affecting the performance. I'll take a look at it.

In VCL, we can draw all the line segments with a call, but it isn't supported for FMX. Look at this ticket (and vote if you like).

[Leo_]

Hello again, and thank you for taking the time to look at this.

Yes, I also think that ....points out of the screen are affecting the performance

I would very much appreciate if you could have a look at it. My main app is a bit more complex than my demo app, and it would save me a lot of "work-around code" if points outside the screen did not affect the performance at the rate it does.

I saw your Embarcadero ticket and I'll vote for sure

You: Otherwise, how were you verifying the performance?
The label at the top displays number of milliseconds between each draw. Increases as number of points are added.


regards,
Leo

[Yeray]

Hello,

Removing this line improves the performance:

Code: Select all

SeriesLiveTracking.XValues.Order := loNone;

[Leo_]

Wow, yes that really made a huge difference!

Thank you so much.

regards,
Leo