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.
I think that OrderedNumericXAxis would be an excellent feature request: http://devcenter.infragistics.com/Protected/RequestFeature.aspx
It seems to me like it would be a good idea to add it to the product with high priority as this scenario has cropped up before, but many factors would affect how soon it would make it into the product. You could email productmanager@infragistics.com if you would like to discuss the matter further. CategoryDateTimeXAxis was designed to suit this scenario with DateTime data, but it would be quite useful to have a generalized x axis (and y axis for that matter) that performed this function for scatter plots. The more constraints the chart it allowed to place on the data, the more performance on that data will approach the performance of the CategoryXAxis.
Also, we are always looking to further improve the performance of the generalized scatter case. So I'll take a look at your sample, were it seems there might be a rendering bug, and let you know if there is anything you can do in the application side to speed things up, or that we can do to improve the performance.
One other thing I can mention is that if you use a fixed axis labels extent for the y axis, this can often help performance of initial display and zooming. If you allow the labels to automatically adjust the width of the label area this can often result in the chart having to be rerendered to accomodate. You can pick a fixed axis extent like this:
<ig:NumericYAxis.LabelSettings>
<ig:AxisLabelSettings Extent="50" />
</ig:NumericYAxis.LabelSettings>
I'll get back to you with a bug number for the rendering artifacts, as I suspect it must be an issue with ScatterLineSeries.
Hope this helps!
Graphical corruption on zooming in too far appears to be an issue with the clipping algorithms for this series. Mostly that its falling back on Silverlight's clipper that has some erroneous behavior. I've recorded this as bug number 88467.
The rendering issue seems fixed in the 2011.2 Release (Silverlight 5 version).
Unfortunately I have not been able to get a Feedback on the ScatterLineSeries performance issue. I think I logged the feature request two or three times now but didn't even receive a confirmation email!. Part of the reason I have not been able to pursue this issue further is that the project I have been working on that needs this chart has been put on backlog for a while but its coming up now again.
I did a re-assessment of current Silverlight Charts from various vendors and their performance for my scenario, and Infragistics still seems the top choice. I'd be happy to buy your components, however I need to be sure I can get the performance story right.
I saw that ScatterBase is offered as a base class, do you think it is possible to implement my own FastScatterLineSeries if necessary? Or would Axis be the right extension point?
Did you come up with a scenario where the use of CategoryDateTimeXAxis for the X data would be inappropriate? I think most situations where you have monotonically increasing X values where the x data is non-equidistant probably map back to date time data. But I'm sure there could be some exceptions. But can you think of any examples that would be important to you?
And if the data is non monotonically increasing in x value, then you have a much bigger problem, and it can be rather hard to make any performance gaurantees. Think about the case where you had 1 million completely random x,y points so that you had no choice but to render 1 million line segments on the screen to accurately capture what the image should look like. This is doable, but it makes it hard to maintain interactive performance for panning and zooming. The geometry cannot be simplified without decreasing its fidelity to the data it is trying to represent.
The current ScatterLineSeries does not assume that the data monotonically increases in the X direction so can't do very much to simplify the geometry its being asked to push to the screen.
LineSeries can, however, even in the case where you use CategoryDateTimeXAxis, so that remains my recommendation. If there is a situation, though, were CategoryDateTimeXAxis is inappropriate, lets discuss it, and I can probably help you with a workaround. And in the medium to long term, it would probably help if we added an OrderedX axis as described above. It may even be possible to do this today as a user extension. But I have not investigated this.
The prioritization of that feature work would be aided by any concrete examples you can provide of scenarios where you have monotonically increasing X data but it would be inappropriate to represent them as time values.
You may also want to inquire with productmanager@infragistics.com or developer support, as to whether your feature request has been duly noted.
Hi Graham,
I did actually try to use CategoryDateTimeXAxis (this actually reflects the nature of my data). I did a straightforward transform of my data to generate DateTime timestamps from my x double values.
However, my testing using CategoryDateTimeXAXis and a LineSeries showed that I can still not get smooth panning and zooming when rendering half a million data points on a 1920*1200 screen (using a Phenom X6 CPU @ 3.6 Ghz). When I use the same setup but use a CategoryXAxis, panning and zooming is smooth. The I found the performance of CategoryDateTimeXAxis+LineSeries and NumericXAxis+ScatterLineSeries about the same.
The basic scenario is like this: I have one graph that shows acceleration sensor data recorded at 100Hz. There are other measurements taken at 1 or 0.25Hz approximately. All this data shall be correlated in multiple charts synced via a SyncManager. On the non-acceleration graph I am using NumericXAxis and ScatterLineSeries with no problem since they only show a fraction of the data points but need high accuracy. When I'm using some other type of xAxis on the acceleration graph, it is no longer properly synced with the other two graphs.
I can happily accept inaccuracy when viewing the data "zoomed out", fast zooming and panning is critical. I need the "Level of Detail" to adapt however when zooming into the graph.
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.