Pre loader

Overview Performance Problems

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums


I am using MVVM and am having problems and need you to have a quick look please as this is substantial

1)Run Solution

2)Click on Load, browse to folder Configuration\20120814 and select OK

3) 6 data series will load, the program then adds random data for each trace. The point count for each trace is shown on the form

4) After a few minutes, the update speed of the points reduces (this is not intended) the counter should update each second

5) when the count reaches about 16000 the program is pretty well locked up and non responsive.

It may well be a problem that I have introduced, at least I hope it is, as our intended application will be using very large data sets
Please could you have a look ASAP and get back to me

You have also not replied to the annotation problem I explained in another thread, I sent you example code to show you the problem


  • You must to post comments

Hello there,

I’m investigating this now.

I can confirm if I run the application on my pc, while it doesn’t lock up by 16,000 points, it is certainly slower. What hardware do you have out of interest? It shouldn’t make much difference (unless its really slow). Mine is quad-core i7. 2.4GHz, so nothing stellar, but no sluggard either.

(BTW I’m really impressed with the SciChart application you’ve written in such a short period of time as in the trial. Nice application & really impressive job!)

Now, I ran your test application through DotTrace. The results are attached.

They make interesting reading! Basically the SciChartOverview is responsible for 40% of the time spent on the main thread. Particularly where the overview control is zooming itself to extents on each point added (on each redraw). We haven’t really optimized the overview for performance as it never raised itself as a bottleneck – it has now!

So, my first piece of advice is, remove the overview

The next interesting thing is that the axis drawing takes 10% of the time. In particular, Axis tick-drawing takes 6.4%. Remember if we remove overview all these figures double, so the tick drawing alone is quite significant.

My second recommendation is to Set AxisBase.DrawMinorTicks = false on all XAxes and YAxes

This will reduce the number of lines these are adding to the screen per frame. Axis ticks and labels are drawn using WPF canvases which are far slower than bitmap renderered series, so we want to minimise these if at all possible. If you can handle it setting AxisBase.DrawMinorGridLines = false will further improve performance since it will reduce the number of elements on the screen, however, there is only one set of gridlines for N axes and there are N sets of minor ticks, so minor ticks are the low hanging fruit here.

My third recommendation is to set SciChartSurface.RenderPriority = RenderPriority.Low

What does this do? It puts the priority of the render thread below the priority of mouse and keyboard input. This is really important as once the UI thread approaches saturation you will lose keyboard and mouse interactivity. This will really annoy your users and give you the impression that the application is ‘locked up’. By using priority low for rendering you give control back to the message loop to process mouse and key events and make your application a lot happier. The trade off is the chart rendering may appear more stuttery but it is because redraws are postponed slightly while the WPF message loop is flushed, resulting in a more fluid application experience.

If you want you can go one further and set RenderPriority.Manual. Then you are responsible for calling SciChartSurface.InvalidateElement() after appending points. For instance, you could set a timer and call InvalidateElement() every 1/10th of a second, rather than for each point appended.

My final recommendation is to throttle data appended to the chart, using the DataSeries.Append(IEnumerable<TX> xValues, IEnumerable<TY> yValues) API

The chart dataseries already do a good job of throttling data. For instance, there is not necessarily 1 redraw for each point appended. However, on each point appended some calculations are performed, such as Min Max calculations of the DataSeries, and checking internal state of the chart before pushing a redraw message onto a stack for the renderer thread to pick up. This is a small overhead but if you are calling DataSeries.Append in a tight loop it will soon add up. You can buffer or throttle appends but using the DataSeries.Append(IEnumerable<TX> xValues, IEnumerable<TY> yValues) method. Passing in arrays here of even size 10 or 100 points at a time can significantly improve throughput.

I’ve just tried the above (except for buffering Appends since that would require bigger changes to the code than I can do here) and I’m seeing task manager report a more healthy 7% CPU at ~16k points rather than the 29% I was seeing before. Can you try these and see if you get the same?

Regarding the overview, we’ll work on that. I suggest leaving it out for now and replacing with a scrollbar, calculating the offset based on XAxis.VisibleRange vs. the known DataSeries.XValues

Best regards,

  • wilx
    Thanks, I have made the mods and added appending lots of points at once as above and it all works great now. You say:- "Regarding the overview, we’ll work on that. I suggest leaving it out for now and replacing with a scrollbar, calculating the offset based on XAxis.VisibleRange vs. the known DataSeries.XValues" We do really need the overview sorting, as this one one of the feature that drew us to you product What do you mean by a Scrollbar? What is one of those. Do you have an example and even better one implemented with XAxis.VisibleRange vs. the known DataSeries.XValues? cheers
  • Andrew Burnett-Thompson
    What I mean is if you use the standard WPF ScrollBar control, which has properties of Minimum, Maximum, Value to define its position and a ValueChanged event when the user scrolls, you could write some code to sync the scrollbar position with the chart range (since you have DataSeries.XValues.First(), DataSeries.XValues.Last() and XAxis.VisibleRange). We don't have an example of this, but just suggesting it as another option. Optimizing the overview has gone on our work queue and will be prioritised in due course.
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.