XY-Chart unuseable by killing Main VCL Thread

Hello TMS-Team,

bying TMS Component Pack now serious time has come for a VCL Chart Application,
but TAdvGDIPChartView-Component seems to be killing Main VCL thread and whole
application is unuseable.

(Data) Background :
- Creating quarter year reports of data with charts and manual corrected data
- Data comes up every 30 Minutes, so I will get about 4500 Datasets a quarter each channel
- 3 Channels a involved andshould be displayed in one pane
- Second pane shows corrections on one channel via TChartLink

For checking data customer will use a chart with all data over three month for correcting unwanted events with data faults.

So far so good, now I build up simple test program with adding a Serie to one of two panels in one chart view :

void __fastcall TForm2::Button2Click(TObject Sender)
 int maxCount=4500;//roundabout 3 Month data by 30 minutes
 TDateTime aMeasureTime=Now();
 float aVal=1.5;


 aRootSerie->Name="MySerie "+IntToStr(aRootSerie->Tag);



 aRootSerie->LegendText=aRootSerie->Name+" [unit]";

 for (int i = 0; i < maxCount; i++)
   if (aVal>500)
   {    aVal=Random(50);   }//only to get a visible line, not only random hickhack


This points to real data circumstances!

Adding one Serie this way everything seems to be ok.
Adding a second serie, the whole thing is unuseable !
It takes several seconds before the second XYLine is drawn on the pane
(even after ChartView1->EndUpdate() is processed! in Debuig session )
and then the whole main window/program is freezed by seems unthreaded
or unhandled refresh operation from the chart.
Adding a third serie you know what will happen .... Wait, wait, wait
and it seems application don't come back !!!!

So as I believe in your announcement that this is an advanced charting pack I hope
this is a bug which is quickly repaired, because I by myself has to deliver the software
latest at the end of the your.

If you say it is not possible to handle 3x4500 values/XY-Chartpoints (which I think is
not very much) leave me a note and I have to change to another charting pack.

Best regards

Dirk Roemermann

Sorry, rendering 13500 points simultaneously in a single view is taking a lot of resources. It's actually unclear why you want to render so much points in a single view. Please consider changing the maximum range to a lower number. There is no point in rendering more points than the width in pixels of your screen. From a viewing perspective, this would mean that on an average screen size of 2560 pixels you are rendering almost 2 points per pixel in a single series.

Hello Peter,

thanks for your reply, but as you can think, it would not very helpful for me.
As I described customer wants to see a chart over al data for a quarter of year.
There are also only! 4500 points for every XYLine-serie and it's useful for finding
single faults, that only happens one time.
And on my test with your chart component I can say it can't be the whole story,
when you say rendering 13500 points is a problem.

If I change maxCount in the test code to 15.000, there is no problem to render them,
if I add only one XYLine-serie. I can zoom, scroll and work on my application.

Turning back maxCount to 2000 (which is nearly the current width of my display) and
add 3 xyLine-Series, the effect is not so hard as if I use 4500 dataset's, but a good
performance is something else.

Conclusion must be that the problem is not (only) that there are 15000 points to render in size of
2000 available pixels, but more in painting/syncing multple XYLine-serie.

What do you think ?

Many Thanks

Dirk Roemermann

Dear TMS-team,
about 4 Days are gone and there is no reply to my last request.
So, hat does it mean to me :

(a) Sorry, we didn't find the time to look for your request, we will answer in the near future.
(b) We are looking for the problem, but we didn't find an explanation or solution.
      We will answer in the near future.
(c) Everything is said, don't wait for another statement.

Please leave me a note !

Best regards

Dirk Roemermann


We are currently investigating this here and we provide an answer as soon as possible.

Of these 4 days, 2 days were weekend days. And yes, in the weekend we work less than during a regular workweek day, but even on a Sunday we monitor and answer threads like this. The 2 days before, our team was totally swamped with work to do 3 major releases on Friday. http://www.tmssoftware.com/site/news.asp 
Even with all this high workload, our team internally already took the time on Friday to discuss this issue you reported. The cause of this issue is the expectation to draw more points on the screen than the screen resolution has which does not make much sense and the fact that this drawing is done via GDI+ that performs anti-aliasing on this drawing which is CPU intensive. To make a long story short, the investigation that will done is to see if the filtering operations of the points to draw to reduce these to the nr. of points that really makes sense  to draw will benefit the overall performance or not. This isn't a trivial investigation, so please understand that this will take some time. As always, we will report when we have come to conclusions.

Hello Peter,
Hello Bruno,

thanks for your reply (on Sunday !!!),
it has been good enough for me to see, that something or what is gonna happen.
That's what I can't see with no reply.
So now I know what's going on and I will wait for your next reply.

Thanks and best regards

Dirk Roemermann


We have investigated this here and with the above code we are able to reproduce the slowness, yet you are adding series with a common range, so it only makes sense to display one X-Axis. This should drastically improve performance with multiple series.

  aRootSerie->XAxis->Visible = aRootSerie->Tag == 1;

If you have a common Y-Axis you could also consider having only one Y-Axis, but this shouldn't affect performance. (aRootSerie->YAxis->Visible = aRootSerie->Tag == 1;)

The reason behind this is that for calculating auto-units the chart needs to loop through the complete range (UseFullRange = True). This multiplies by the number of series.

Hello Peter,

as I need only one x-axis this may help to find a solution.
I will try out to fix the problem this way.


Dirk Roemermann


Please let us know if this improves the performance for your application.

Hello Pieter,
project has been new terminated to the end of january,
but I will let you know, when or if it runs.

Best regards

Dirk Roemermann