SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and now iOS Charting & Android Chart Components

Answered
1
0

I’m using your sample WPF code for the XyScatterRenderableSeries and modified the parameters to the GetDampedSinewave generated data to produce 76,800,000 points. This is approximately the maximum amount of data that our company will have to render in any single high density scatter chart.

The performance of rendering 80,000,000 points is staggeringly slower than the original 200 points in the sample. Zooming and panning, and resizing the application window take a very long time (i.e. longer than any customer would like to wait, > 30 seconds).

Is there a faster chart to render approximately 80,000,000 points in < 1 second? Or, any attributes or tricks that I can use to only render points that would actually be shown in the current drawing area? Because, obviously, for a standard chart drawing area and zoom extent, 80,000,000 points rendered on top of each other is over-kill!

My development PC has a top-end NVidia GEForce GTX 660 with the latest graphics driver, running on Windows 8.1 Pro 64-bit, quad core third generation i7 Intel processors, etc. The development environment is Visual Studio 2013, .NET 4.5.1, WPF, latest service packs, latest Windows udpates, etc. Latest and greatest.

I'm also using the latest available SciChart v3.0 Build 3936 BETA.

I'm re-evaluating performance of SciChart for our high density charting needs. The original evaluation was done by a previous developer who is no longer with our company, and we are starting a new project, where I would love to use WPF SciChart, but only if I can prove that performance for high density charting (with Zoom and Pan functionality) is viable for the 80,000,000 data points.

Thanks.

  • You must to post comments
Best Answer
1
0

UPDATE July 2015

We’ve updated and improved the code above to work with v3.4.2 or above of SciChart (the above solution is only compatible with version v3.1) as well as introduced a simple clustering algorithm to achieve over 24FPS for a million points on a scatter chart.

Take a look at the article Insane WPF Scatter Chart performance with Parallel Rendering for further details.

enter image description here

Best regards,
Andrew

  • You must to post comments
Good Answer
2
0

Hi there,

Thanks for your enquiry about SciChart! Ok what you are trying to do is going to be extremely intensive on any charting library, and any hardware. However I think we may be able to improve on it. SciChart is more dependent on CPU than on GPU so if you have a faster CPU and faster memory it will be more beneficial than a faster GPU.

The scatter plots cannot be resampled in the same way that line plots do. Line plots we can make some basic assumptions and output a few thousand points for many millions in to draw on the screen. For scatter we cannot do this. The best we can do is cluster, which is itself a CPU/memory intensive algorithm.

First suggestion you should try is to check if your data is sorted when appended to SciChart. If not sorted then any indexing operations (used a lot in zoom and pan) cannot use faster binary search. Array.Sort provides a fast way of sorting (faster than LINQ OrderBy).

Second suggestion you should try is to enable the ResamplingMode.Cluster2D on your XyScatterRenderableSeries (SciChart v3.0 only). This is an experimental algorithm which attempts to group close points. It will depend on distribution of data as to how well it reduces the dataset. Also note this is a memory and CPU intensive resampling algorithm, not like the extremely fast MinMax, MinMaxUneven and Auto algorithms that we have for line series. If it does not help, or makes it worse, then I suggest setting ResamplingMode back to Auto (the default on SciChart v3.0).

Third suggestion is via this workaround to enable drawing scatter points in parallel (SciChart v3.0 only). Make sure you apply your ParallelEllipsePointMarker in XAML to replace the standard EllipsePointMarker

    public class ParallelEllipsePointMarker : BasePointMarker
    {
        /// <summary>
        /// When overridden in a derived class, draws the point markers at specified collection of <see cref="Point" /> centers
        /// </summary>
        /// <param name="context">The RenderContext to draw with</param>
        /// <param name="centers">The Centres of the point markers</param>
        /// <param name="pen">The default Stroke pen (if current pen is not set)</param>
        /// <param name="brush">The default Fill brush (if current brush is not set)</param>
        /// <seealso cref="IRenderContext2D" />
        ///   <seealso cref="IPen2D" />
        ///   <seealso cref="IBrush2D" />
        protected override void DrawInternal(IRenderContext2D context, IEnumerable<Point> centers, IPen2D pen, IBrush2D brush)
        {
            var viewportRect = new Rect(new Point(0, 0), context.ViewportSize);

            float width = (float) Width;
            float height = (float) Height;

            Action<Point> drawOp = (center) =>
                {
                    if (IsInBounds(center, width, height, viewportRect))
                    {
                        context.DrawEllipse(width, height, center, brush, pen);
                    }
                };
 
            // This will only work for some drawing functions, like DrawEllipse. Consider this experimental
            Parallel.ForEach(centers, drawOp);
        }

        private bool IsInBounds(Point centre, float width, float height, Rect viewportRect)
        {
            var markerRect = new Rect(centre.X - width/2, centre.Y - height/2, width, height);
            viewportRect.Intersect(markerRect);
            return !viewportRect.IsEmpty;
        }
    }

Please try the above and let me know your findings.

UPDATE

Just a note on the above. I actually tried rendering 78M points in our scatter example using EllipsePointMarker vs. ParallelEllipsePointMarker, ResamplingMode=Cluster2D vs. Auto.

What we found is (I am running on a Virtual machine inside i7 Quad Core macbook pro, with 2 of 4 cores assigned, so not exactly the highest end machine but good nevertheless):

  • With 78M points, EllipsePointMarker and ResamplingMode.Auto (as standard), it took 20 seconds to generate 78,000,000 points, 10 seconds to append and then redraw just froze the machine.
  • With 78M points, ParallelEllipsePointMarker and ResamplingMode.Auto, redraw takes about 10 seconds
  • With 78M points, ParallelEllipsePointMarker and ResamplingMode.Cluster2D, no noticeable difference in redraw (clustering time trades off against drawing time)

However, at 10,000,000 points we found that ParallelEllipsePointMarker and optionally ResamplingMode.Cluster2D the redraw takes about a second. As you zoom in, performance improves significantly due to virtualisation. So, I am confident that SciChart 3.0 can render a scatter plot with 10M points. It won’t be super high frame-rate like our line chart examples but it will be able to display data and allow basic interactions.

I believe that 78M points is optimistic, there is not much we can do about this in the short term, we are operating near the limits of technology as it is!

Finally, we are always interested in performance, achieving it, maintaining it and always looking for ways to improve.

Let me know your feedback.

Best regards,
Andrew

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.

STAY UPDATED
Signup now and we’ll keep you updated with product developments and you will be notified the moment SciChart iOS Charts is released and available.
STAY UPDATED
Signup now and we’ll keep you updated with product developments and you will be notified the moment SciChart Android Charts is released and available.
THANK YOU
Your details have been received.
We like to make sure we only send information to clients who want to hear from us, so if you check your email now, you will find a confirmation email from us. Please click the confirm link and you'll will be added to our updates.