This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi there, I have a chart with x-axis as DateTime and Y-axis as double, it contains a scatter series and line series. When we zoom to some extends, the whole application is frozen, since the ActualMin and ActualMax for axis is keeping change. I set the axis MinimumRange = 1.0, it does the same, in some point, it gets to the stage of unresponsive even faster, getting to a state of OutOfStackException. Same thing, if x-axis is double. How do we fix this problem? Thanks, Gordon |
|
|
Hello Gordon The StackOverflowException was also pointed out by another customer yesterday, so this is fixed in the current nightly build. As for the bad performance, what is most likely happening here is the chart is being zoomed in so far that a single line segment between 2 data points is being stretched to be thousands of pixels outside the chart viewport. WPF will try to render the entire span of this line causing it to slow down. The usual work around to this is to set the MinimumRange to an appropriate value so that more than 2 data points of the line series can fit within the chart viewport. If you can confirm that a single line segment being streached/zoomed in very far sounds like what is happening in your case (i.e.The data points at either end of a line segment have been zoomed far off either side of the viewport), then I may be able to resolve this. What I could try and do is interpolate either end of such line segment and move the rendered start and end points of the line to be closer to the edge of the viewport which will reduce the strain on the WPF rendering. -Jason Fauchelle |
|
|
Thanks, Jason It was zoomed very far. When the zooming is provided, the user will keep zooming (at least our QA will do the extremely testing on it) until it reaches to the end... |
|
|
Hi Jason, Any follow ups on this? Gordon |
|
|
Hi Gordon I'm working on this right now. I'll be replying back soon when it's done. -Jason Fauchelle |
|
|
Hello Gordon To help work on this, I need a little more information. You mentioned that the chart contains a scatter series and a line series. Is it actually a SplineSeries? because this is the main series that it producing the most performance issues when zoomed in. How many series is this chart displaying, and how many data points do they each have? If you can temporarily the line series, and then try reproduce the performance problem, and then add the line series back in and remove the scatter series, which series produces the most performance problem? -Jason Fauchelle |
|
|
Hi Jason, It only contains one LineSeries and One Scatter series, I did not use SplineSeries at all. The number of datapoints is not important here, we tried to use 50, 30, or 100, 500, they all acting like that when zoom to extreme condition (too far). I will try lineSereis and scatter series separately tomorrow (we have 14-15 hrs different). Thanks, Gordon |
|
|
We got the sample performance problem when zooming, I have posted a thread before your thread. And yesterday, I downloaded the new nightly build version WpfElements6Professional-20140622.msi, it seems like that the problem is not solved yet. I cannot explain to my QA, and the MinimumRange does not work. I don't know what is the unit of the MinimumRange, so I don't how to set the MinimumRange |
|
|
Hi Jason, As promised yesterday, I tried it out with single LineSeries and single ScatterSeries and the observation is: 1) For LineSeries, the zooming is ok, but at some extreme extends, the line will disappear, I guess if there is no point in the zoomed area, it make sense for line to disappear. 2) For Scatterseries, if you continue to zoom around one point, it will getting slower and slower and at the end, UI will be unresponsive. Zooming in white place (without data point) it also is unresponsive. My suggestion is if the zooming area does not include 2nd point, the zooming should be stopped, by either clicking the area or using mouse wheel. It is impossible for us to make this adjustment, so it would be good for you guys to do it. Thanks, Gordon |
|
|
Thanks Gordon Is it that the entire application freezes? Or is it only the chart zooming that stops working? I have reproduced the latter which isn't as bad as freezing the whole application. If you zoom in really far to the point where it stops zooming, and then press the "Home" key, will the chart zoom back out and become responsive again? The range of one or both of the axis may be reaching so close to zero that the zooming function gets locked. The MinimumRange property is there to prevent this. Could you please try using the MinimumRange property to prevent the user from zooming in to extreme levels and see if this works well. -Jason Fauchelle |
|
|
Hi Jason, The whole application is unresponsive. I also tried to set MinimumRange=1, the condition is improved, the chart is not very responsive and the application will be unresponsive when the chart is still doing the "updating", but the time is much short. I was using June 24, 2014 nightly build. Thanks, Gordon |
|
|
Hello Gordon The previous nightly build still had a stack overflow/infinite loop issue when zooming in which may be related to the unresponsiveness of your application. This bug was the only way I've been able to reproduce the application freeze. This bug will be resolved in the next nightly build, though I'm not totally certain if it is the same issue that you've seen. In any case, using the MinimumRange property is the best way to improve the zooming experience of you charts. -Jason Fauchelle |
|
|
Hi Jason, I downloaded the June 25th nightly build, the problem seems fixed. Thanks, Gordon |
|
|
Hi Jason, I spoke too soon. I downloaded July 02, 2014's nightly build, if I have a scatter series and a few of line series, when zooming to some extends, the problem persists. Thanks, Gordon |
|
|
Hello Gordon This should be the same issue as this one: http://www.mindscapehq.com/forums/thread/2026178 -Jason Fauchelle |
|
|
Hi Jason, I dig more into your source code. This time I did not use any logarithmic axis at all. What I did is trying to set zoom programmatically. I have a bar plot with the following data:
I set Y-Axis' Maximum = "Maximum" and Minimum = "newW1L3UBAK(3, 5)" as in the last element and first element in the data array. Since there is too many bars, after the graph loaded, I want to set the Y-Axis' ActualMinimum = "newW1UBAI*newW1UBAJ" (wait about 200 milliseconds to set it) The OutOfStackException is thrown by the system. You may need to load the plot and Set Y-Axis ActualMinimum and ActualMaximum a few times to make it happen. Trace into your source code and the deadlock happens in the property ChartAxis.ActuamMinimumValue
See the comment line "Infinite Loop Happens here" in above code section. When it is happening the
for the code:
I am not sure if it is wise to put ActuamMinimumValue = 'value' inside the property ActualMinimumValue's set method. I really wish I have the time to give you reproduce project, but we have our own bugs to fix. This is become more important for us. We are using July 02, 2014 nightly build with version 6.0. Please fix them, Thanks Gordon |
|
|
Hello Gordon Thanks for the further information. I was unable to reproduce this issue, but I've made a fix for the next nightly build which should solve the problem. One thing I noticed is that at one point in the code you posted, we were setting ActualMaximum instead of ActualMaximumValue. This code is related to my previous attempt at solving this stack overflow issue and so may be related to the current issue, but should only be in effect if you are zooming close to the minimum of the chart, not the maximum. In any case, I've also included a lock variable to avoid any infinite loop here. Automated and manual tests all check out fine. Let me know if this solves the problem. -Jason Fauchelle |
|
|
Thanks, Jason, I am looking forward to the fixes. By the way, if I want to set the ActualMinimum and ActualMaximum programatically, when to do that. If set the them after set Maximum/Minimum, it will not work. Since the ActualMin/ActualMax get updated so often until the plots is finishing loading. Thanks, Gordon |
|
|
Hello Gordon ActualMin/ActualMax need to be set after Minimum/Maximum because Minimum/Maximum are constraints. It is best to set them after the ItemsSource has been set. If you are having troubles with the Chart control trying to set the ActualMin/ActualMax values for you, you could try set the IsAutoViewportEnabled property on the axes to false. You could either set this to false before setting the items source, and then set it to true again, or you could try leave it as false all the time which should give you full control of setting the ActualMin/ActualMax values. -Jason Fauchelle |
|
|
Hi Jason, If I set it to false all the time, the whole application is not very responsive at all and the curves there before will not show... I set the IsAutoViewportEnabled = false before I add the curve and set it to true after I add the curve, and it does not have much effects, I still need to use a timer to set ActualMinimum/ActualMaximum later. Otherwise it is not working at all. But it is so hard to let the timer kicks in since we don't know when the view port is set down and ActualMinimum/ActualMaximum will not be get updated anymore. Some times it does not go through our view model anymore once the plot is added to the graph, for example, put chart in a tab control and switch back and forth on the tab items. Gordon |
|