I'm trying to plot roughly a million data points (x,y) (floats) into a xamDataChart. When using a CategoryXAxis and LineSeries, the performance is excellent and zooming is smooth.
When using a NumericXAxis and a ScatterLineSeries, I am experiencing a significant loss in performance. This can be reproduced by adapting the "BindingHighVolumeData" sample.
Also, I am experiencing rendering artifacts when zooming deep into the graph:
Thes issues do not occur when using a CategoryXAxis.
I am currently evaluating to buy Infragistics DV for Silverlight for its stellar performance. However, I do need a precise x,y plot. As far as I understand CategoryXAxis will align my data points with a constant x spacing, correct?
Why is the performance of ScatterLineSeries so much worse? Is there a recommended way to draw a high performance xy line plot?
Hi,
There are unfortunately far less contraints on pure XY data rather than ordered category data that cannot regress to earlier x values from higher x values. We are always looking to make the scatter cases better, but because the data is less constrained it will always be far less efficient than using a category series.
So, if your data only ever has an increasing x value, you are far better off using a series with a category axis than a numeric x axis.
The CategoryXAxis will align your data points with a constant x spacing, but the CategoryDateTimeXAxis, will space them based on the date difference between the points, rather than spacing them all equally. This is a slight relaxation of constraints of the CategoryXAxis, so the CategoryDateTimeXAxis will likewise never perform as well as the CategoryXAxis, but its much closer in performance compared to NumericXAxis based series. CategoryDateTimeXAxis also doesn't assume your data is pre sorted by date, so there is a bit of a hit there, especially if you are updating the data with high frequency.
Nevertheless, you are much better off using CategoryDateTimeXAxis or CategoryXAxis if those match the requirements of your data. The complete lack of assumptions we can make about pure XY data make it much harder to retain interactivity when large volumes are thrown at the series.
That being said, if you can provide a sample with your scenario I can examine whether there is anything to be done to improve the x-y plot performance for your case. It may be useful if we were to add a mode to the scatter plots where the user could specify that the data was constrained to only increase in X, in which case the axis could behave more like CategoryDateTimeXAxis, but not necessarily be related to dates. Would that sound like a useful feature request?
I haven't seen that graphical distortion with scatter line before. Do you have a sample that reproduces it? Which version are you evaluating? As an additional note, there are many performance improvements in 11.1, so if you are running a previous trial version, you may want to grab the 11.1 version.
There was a performance fix that should be in the most recent version of 11.1 that should help scatter line performance, as the chart was doing too much work even though the markers were turned off. I don't believe the trial version has this fix though. If you can provide a sample of the poor performance I can tell you how it performs with the latest version though.
Hope this helps! Let me know if you have any other questions.
-Graham
Hi Graham, thanks for your fast feedback. I have attached a sample repro for the artifacts encountered when using a NumericXAxis. Let me know if you can reproduce the issue. The version I am using was downloaded just yesterday, so I assume it's the latest.
CategoryXAxis actually is an option in most scenarios, however it results in a loss of visual accuracy in my case. CategoryDateTimeXAxis is a decent choice, however not all data is suited to be transformed into a DateTime, so I'm a bit concerned here.
I do have floating point x/y coordinates (think of a simple waveform) that are guaranteed to be in correct order. Transforming all x values into a DateTime will result in a precision loss and is slow and cumbersome to do.
Your feature suggestion (OrderedNumericXAxis) is exactly what I would wish the control offered out of the box. Is it likely this will be implemented? I think its a fairly common scenario.
Its expected that CategoryDateTimeXAxis should be slower than CategoryXAxis, but it should still be much faster than the equivalent ScatterLineSeries. Could you provide me with a bit more detail about your scenario:
Knowing what data you are using in that plot should help a lot because sometimes the performance can be sensitive to this, and you may have hit a bad case that we can alleviate or fix. A concrete sample would help a lot.
Note, that if you are mocking up some data to test performance, make sure that it has some resemblence to the real data that will be coming from the sensor as there are many easy ways to mock up data that aren't especially realistic, yet can create performance problems due to their dissimilarity to the most common use cases. Is it the same data that you've tried feeding to the CategoryXAxis?
Also note, that on the series you are using there is a property called Resolution which defaults to 1 for most series. You can actually raise this to a higher value which will decrease the fidelity of the line to the data, but as you zoom in and the individual points spread out, they will begin to fit the data better. Depending on the shape of your data, it may not turn out that this helps you, but you may want to give it a try if the fidelity of the zoomed out chart is less important than the zoomed in view.
You can think of the Resolution property as if it is a measure of the pixel distance that two data points have to be from each other for the chart to consider them as two distinct values for display. By default, if the data point would be in a seperate pixel then it is considered distinct, but if you raised the Resolution to, say, 4, the shape of the displayed series will adjust due to the fact that it considers many more points coincident to eachother. You will see a banded shape that notifies you of the y range of the values over that section of 4 pixels.
Its possible, however, with the CategoryDateTimeXAxis that you may have certain data sets where this doesn't help the performance much. Let me know.
Also note:
Hi Graham,
All testing refers to the latest 2011 Vol2 SL5 release.
Markers are set to none for all graphs. My data usually contains regular patterns, much similar to a distorted sine wave.
I have fixed my issues with the three charts being unsynced by using CategoryDateTimeXAxis on all charts, but I'm still seeing performance issues. If you let me know an email adress, I'd be happy to send you my sample project plus sample data (it's around 10mb). The sample data I'm using is the real data, no faked data. I assume your sampling algorithms play bad with the type of data I'm using. It would be great if you could expose an API where one could hook in a custom sampling algorithm.
I tried playing with the resolution property of the LineSeries, but even though I can see a difference in the fidelity of the graph, I'm not seeing a considerable performance improvement. I do see some improvements if I make the chart smaller so only a few pixels have to be rendered.
You can send the sample to gmurray@infragistics.com
The fix has been checked in, so barring any unforeseen circumstances you should see it in an upcoming service release. I'll also check your scenario against the new volume release we are working on and see if there is any other tuning we can fit in.
That's grand. Let me know when I can expect this to be fixed. I think this should really make the chart performant enough for my purposes.
Bug number is 102640
Johannes,
It looks like there has been some sort of regression which is causing the axis to resort its column every time the zoom level changes. I'll get back to you with a bug number.
Its definitely not supposed to be resorting unless the data has changed. So either you've discovered a regression bug or something in the way you are using the chart is causing it to resort the data when it doesn't need to. I'll look into your sample tomorrow morning and see if I can determine what might be going on.