Why does WPF Vector Plot take so long (10 sec) to Render 4x1000 points when zoomed in tight on Y Axis?

[ellisda]

This is a bit of a pathological take on a problem we're seeing in our use of the WPF graph, but I hope it highlights the source of the issue.

The attached simple app has a WPF Graph (RenderMode = Vector) and 4 LinePlotRenderers, each plotting some 1000 points (data provided). When you try to resize the window (or maximize the graph), it takes around 10 sec to render the graph (1440x900 resolution). This example is zoomed in very tight on some pathologically noisy data; I think the problem stems, somehow, from the fact that the noisy data is going off the top and bottom of the screen with each point.

If you zoom out (ex: set Y Range to [-5000, 5000]) the render performance improves to ~1 sec, but we don't want to artificially limit our users in their zooming.

I've found that switching to Raster or turning off AntiAliasing helps, but we would like to use the Vector rendering for aesthetics and because Raster LinePlotRender doesn't allow us to set StrokeThickness.

Any suggestions how we can keep anti-aliased Vector and improve rendering performance?

(I've tried multiple configuration, but I'm developing AnyCPU, on an Intel i5 with integrated NVidia graphics)

[FoxSquirrel]

When I run the program, I see the delay, however, not quite 10 seconds.  It's generally 2 seconds for me.  I'm guessing that you are just trying to draw way too much in such a small area.  I'm not sure if there is an easy way to just make it so when you resize, you don't have to render again.  However, one way might be to not use as much data.  I'm not sure what your requirements are with this specific program though.

[ellisda]

Hi Jesse. Did you maximize the window and get a 2 sec redraw? (at what monitor resolution?). I get a ~2 sec initial draw at application launch, but when I maximize the window to 1600x900 (correction), I get a redraw of ~10 sec. At 1366 x 768, I see ~7 sec redraw.

As for too many points. We're already doing a lot of pre-culling / decimation of the data before plotting. This scenario shows ~1000 points on each of 4 plots, which I thought was reasonable for a graph that might be 1000+ pixels wide. Our original data often has 1 million points x 4 plots, but we downsample to ~1000 as is posted here. How would you recommend to use less data (i.e. fewer points, or did you mean modify y values)?

To clarify, the issue we have in our full application isn't when the screen is resized (that happens rarely). But sometimes our users zoom in on noisy data and it takes ~5 sec to redraw (sometimes causing window to be labeled "Not Responding", etc). What I've posted here, is an exaggerated zoom-in, based on data from our real world system. I'll acknowledge the data as plotted isn't a useful visualization, but I don't feel that I should restrict what the users can zoom in on. They've complained about this performance.

Thanks,

-David

[ellisda]

Here is a revised zip file that shows something closer to our original data. I've added two buttons to easily toggle between a fast render and a slow render, where the only difference is the y axis Range.

I don't understand why the zoomed in view takes an order of magnitude longer to render (~10 sec vs. ~0.5 sec, at 1600x900 window size). I've tried disabling all decimation as described here, but it didn't seem to alter the rendering times. The XAML comments have a repro with just WPF Path objects, but I couldn't workaround it there either... (?? have the NI engineers logged this issue with WPF team??)

Thanks for any help,

-David

[phansen · Accepted solution]

After looking at your example, I believe your analysis is correct: the generated WPF Path objects are taking significantly longer to render when they become visually noisier. Since the purpose of vector mode is to provide the same visual rendering as WPF, it is limited by the performance of the WPF visuals.

As a workaround for stroke thickness support in raster, you may be able to use the attached custom renderer in place of a line renderer. The custom renderer uses overdrawing to simulate thicker lines (though it is limited by the resolution of the raster bitmap).

[ellisda]

Thanks Paul. If you have any intuition as to why the WPF Visual performance degrades, or how to improve it, I'd love to hear it.

I tried looking at Perforator and the Visual Profiler but I didn't learn anything actionable.

I looked at the chart control from the WPF Toolkit and it sees a similar performance issue (their control generates a PolyLine instead of a Path, but performance appears to be the same). I also looked at a different WPF-based product (rhymes with "Pi Chart"), but they display the graph as an Image element. Presumably they are rendering the image in some custom fashion without WPF visuals and hence do not observe the performance hit.

Going forward, I may try to detect this situation in code and prevent plotting overly noisy data to the graph (i.e. show user a "data is too noisy to display" annotation instead), but that feels pretty inelegant...

Fingers crossed for a new release in March 2014...

Cheers,

-David