Hi Infragistics Support,
Can you provide some guidance/tips/suggestions for a new user of your controls?
I have a requirement to display ~400 series. Each with ~6000 points (for a total of ~2,400,000 points). Will Infragistics WPF chart control be able to handle this and still provide a good user experience?
Some other requirements: will need zoom and pan, Series hit testing but not necessarily point (marker) hit testing. I believe the data will normally be evenly spaced in the X direction but cannot guarantee that.
How would Infragistics recommend charting this data to achieve a good user experience (i.e. the char is still "snappy")?
Please let me know if any more information would help. Thanks!
Chris
Hey Chris,
This one is an interesting challenge! XamDataChart is very much tuned toward rendering complex visuals (a single line with 2 million points, for example) with great performance, but when you start throwing in an extreme number of visuals then the underlying platform (WPF, in this case) starts to show some strain, or, in some cases, you start hitting some areas of the chart hard that haven't been tuned as aggressively as others.
WPF really doesn't appreciate scenarios where there are many many visuals in the visual tree, which makes this sort of scenario a big challenge. However there are things you can do to arrange this scenario such that it performs well, I believe.
First of all, though, you may want to reconsider the requirement? What story is being told by having that many series present at once? Are you trying to show the shape of many overlapping data sets? In which case, it may be more useful to coalesce the data into a single, or multiple min/max data sets and plot them as RangeAreaSeries, which can show a min/max range. You could even use this in a hybrid scenario whereby you switch to showing the individual series once the user has zoomed in to a sufficient level. I realize, however, that this may not fit your requirements perfectly.
Here's some stuff you can do to tune the scenario where an extreme number of series are present:
With the above advice combined, your scenario seems to perform pretty well for me. Here's a gist with the code I was using (minus, disabling the mouse wheel):
https://gist.github.com/gmurray81/9a4fbcb71af824c51716
Hope this helps! Let me know if you have any other questions.
-Graham
Hi Graham,
Thanks for the quick response. A bit of detail - we're displaying the data acquired from a scientific instrument that collects signal from a "plate" of 396 wells over time. Each series represent the amount of fluorescence detected in each well on the plate. Once the data is captured, the scientists need to see all signal data at once to pick out what they are looking for. But once the data is acquired - it will never change.
I had already deduced a couple of your suggestions (the markers and legend) and we don't have much else in the charts airspace. (We have to add a dozen or so widgets to mark some peaks on one of the curves (some issues here which I will post about later if we stay with Infragistics) but that doesn't seem to cause any issues.)
I did not know about the bitmap caching mode and turned that on. Can't see too much of a difference with that tweak. When I get some more time I will play with the mouse wheel and panning suggestions.
I noticed in your sample code you are using a LineSeries. We're using a ScatterLineSeries. Would that make much of a difference performance wise? We could certainly use LineSeries if the X data is evenly spaced (which it will be most of the time) and when it isn't throw in the odd ScatterLineSeries to handle it.... thoughts?
Thanks for the advice! :)
Chris,
ScatterLineSeries vs LineSeries performance can vary a bit depending on context. I've certainly seen a few scenarios in which ScatterLineSeries can outperform line series, but, in general LineSeries will be a better performer since we can much more aggressively and efficiently manage the complexity of the rendered line. This, however, makes a lot more difference when there is lots of data present in each line, rather than small amounts of data present in each line. If it isn't too much trouble, I'd try out both scenarios and see if using LineSeries helps.
Do you have any screenshots you can share of the shape of the data? One thing to know is that some line shapes are very problematic for WPF's rendering pipeline. Lines that are extremely noisy in the y direction seem to hit a degenerative case in their polygon tesselator and all performance gets trashed even with a comparatively small amount of data in the line. If you multiply this by 400, it creates a big headache. This scenario usually comes up if someone is using mock data where they have generated it using completely random y values at each step, however, if the data from your sensors is sufficiently noisy, then perhaps that could also be creating the issue. That one would be a harder fix, since you are essentially taking a degenerative performance issue for WPF and multiplying that overhead by 400. There are a couple routes to try if this is the case, but I'll wait till we determine that is the issue.
If it is possible to share the data in use, that would, of course, aid with the diagnosis.
What kind of delay are you currently perceiving on zoom interactions? I don't know if you tried the sample code I sent, but I think it was generally sub-second reaction, and the configuration used helped mitigate any issues where you would perceive a drop in framerate.
BTW, with bitmapcache, you are mostly going to perceive the difference in the smoothness of the crosshair and the tooltip, and the zoom drag rectangle. If you see those things slowing down, that is generally an indication that you have constructed something that WPF is having difficultly painting. The chart itself is doing next to no cogitating when displaying tooltips and crosshairs, but when you float stuff over the airspace of the series, WPF needs to repaint and recompose them, so if they are especially expensive to paint, havoc ensues. The counter to this is to ask that the individual series (set it at that level, not the chart level) should have their visuals cached as bitmaps. This adds a bit of overhead to each time a series gets rendered, but means that WPF doesn't need to repaint each one when it recomposes the plot area.
Thanks,
Yes, I can share my sample application. Not publicly though so please send an email address to me (I assume you can see my email) and I can zip and send.
You can send it to my first initial + my last name at infragistics.com (see my profile to the left)
My anti-robot caution is useless, however, as I believe my email address exists elsewhere on these forums unmangled. Also, if you have access to the support case associated with this forum thread, you can attach the file directly to the case.
-Graham.
Thanks for further suggestions. We're good with peaks and such - we've got our own library to do all the "heavy lifting" math on the data - we'll just be adding a dozen or so annotations to the chart at the proper places (I will be raising an issue with this later though...).
Awesome, glad I could help! Do let me know if you need any more assistance.
One note on the hairline mode, if you guys are also interested in negative peaks, you may want to alter the behavior whereby rather than it picking the min or max as the representative points for a range that it could first compute the median value for the series data, and select either min or max at any given point in time based on whether you are greater or less than the median, and maybe that will ensure that the maxima and minima are well represented.
As for praise, totally not required, just glad I could help! I'll make sure to send my manager this forum thread, though. I believe there is an opportunity to share feedback when we close a case, whether it positive or negative, but I'm not super familiar with the process, myself.
I've gotten a chance to look at what you posted WRT the OrderedScatterLineSeries. First off, thanks again for working with me. Let me know who I should email to give you some public praise! :)
So with the new series type. Seems to be working. :) I can see/feel an improvement in responsiveness. Especially WRT drag zooming. Of course this is all subjective but it does feel faster. We like the hairline so that is a plus. The BitmapCache on/off makes a big difference in performance so we'll stay with it on. In my (limited) playing with the Resolution setting, I found that the loss of resolution was too much for any gains in performance - even going from 1 to 2 I saw smooth peaks going to sharp peaks. And since we're interested in peaks.... that wasn't what we needed so we'll probably stay away from changing that.
So to wrap up, I think we'll stick with your enhancement. At some point soon, I'll try to get to your suggestions page to add this as an enhancement.
Neat, let me know how it goes!
Hi Graham.
This looks cool. I'm deep in the bowels of coding up a module to read NetCDF scientific data files right now so I can't get to this right away. Hopefully this afternoon (I'm in the PST timezone) I'll be able to get to it. If not, Monday. I'll let you know how it goes.