Hello Infragistics team!
I created a test application based on your WPF DV Samples Feature Browser for XamDataChart. The sample is called "Binding Dynamic Data" I have 4 charts with 2 ScatterLineSeries on each of them. Each Series has 500 points. But updating these 4 Charts needs nearly 7-8 seconds! Maybe I developed something wrong? Is it possible to update 5-10 charts with 3-4 series on the each of them within 1 second? In our real application it is require to update many Charts in real time (it can be 10 Charts with 4 series on each of them with 300-500 points in each series). And this data are NOT Added one point by one. We load this Data from a database and we need to show it very fast. But what about your "Million Data Points, Milisecond Updates" (c) ??
If required, I can send you the source code of my test application.
Thanks a lot!
Hello,
Here is the support ticket number: CAS-67943-BPWRZV we have created on your behalf. I am going to link it to development issue: 80441, that Graham created, so that you get automatically updated when a Feature Release containing the fix is available for download. You can get the new version from our website’s “My IG”, “My Keys & Downloads” tags: https://es.infragistics.com/Membership/Default.aspx?panel=Downloads#Downloads
You can also monitor the support ticket’s progress through the “My Support Activity” tag: https://es.infragistics.com/Membership/MySupport.aspx
Hi,First of all - Thank you for your detailed answer.
Some words about our real app. We have a big data collection, which is shown in charts. On one screen (Window) there can be 9 (as rule, but can be more than 9) charts. In each chart there are a maximum of 4 series (2 on the left and 2 on the right axis). These charts are updated in 2 modes: "Real mode" (when data is measured) and "Post mode" (when all data measured and we only need to load it from the database and show on charts).
In my sample app markers are really turned off. But in our real app we use 2 of our own chart types: "TimeChart" and "XYChart".
In "TimeChart" we have the current Time on the X-Axis. For these charts we use ScatterLineSeries (without any markers). In "XYChart" on the X-Axis there is one of the measured data. So, "XYChart" is a function Y(X). And there we use ScatterSeries. And on these series we use markers. Because we need not lines, but points in these "XYCharts". And for the markers we use some data template, because if I understand right, your markers have a fixed size. But they are too large for our charts.
But you say, that markers are most expensive aspects of the chart's rendering. What is the best solution for us?
I attach a sample which shows our usual screen (Window).
Why we use ScatterSeries instead CategorySeries? As I know CategorySeries use only ValueMemberPath. So, it uses only data for Y-Axis. And data on X-Axis is shown with fixed interval. But as I describe above, we use both: X and Y data for each point in Series.
So, if we are mistaken about CategorySeries - please, put us right .
The bug has been marked as resolved. I believe it may be too late for release in the imminent service release, but should be included in the next.
-Graham
I can confirm for you that it seems the initial display lag is being caused by the erroneous marker layout, and shall be corrected shortly.
If you can provide any sample for what you are going for with updates over time, I can try to make sure that scenario is well supported also, but as I mentioned above, some of the performance possibilities will be somewhat hindered by the number of series and the necessity of using a scatter line.
Hope I can help!
Also, make sure when evaluating performance in WPF to not run with the debugger attached. Oftentimes studio will be configured to log lots of information about the bindings that are occuring in the application. In the case where markers are enabled there are LOTS of bindings occuring, so if there is verbose logging going on it can seriously and artificially reduce the performance of the application. I don't necessarily think you are experiencing that on your end, but keep it in mind for your testing.