WPF Performance rendering for custom sound wave control

Question

I'm currently looking at writing a sound wave visualisation control for WPF. In fact it can render any sort of line graph data; it doesn't have to be a sound wave. As long as the data is a discrete set of samples it will render it.

I have it working; however the performance is not that desirable. I have done a lot of code optimisation to make the OnRender method work quickly. I've tested it with a profiler and it shows it runs at around 110ms, which should be fine.

However I'm seeing the application stall a lot and the profiler isn't showing why.

During my tests I've noticed it may have something to do with fill rate. By that I mean the number of pixels being drawn. My test data consists of a sin wave, at 41000hz over 20 seconds. This produces 812000 samples. Now my control optimises this data depending on the zoom scale the user is viewing the wave at. The entire wave will be drawn using around 6000 lines draws.

If I zoom a long way into the wave so I only render two full sin waves, I still do around 6000 line draws. The CPU time is around the same, at 110ms but the application is smooth and doesn't stall, which seemed strange at first.

However when looking at it the full wave draw touches almost every pixel. The chart draws a green line, which when zoomed out overwrite the entire background of the graph control. When zoomed all the way in only a small amount the background is overdrawn.

I work as a game programmer so I recognise this issue could be caused by fill rate limits. If the line draw is touching every pixel then it becomes slow to draw, irrespective of the number of line draws. However I would not expect this to be the case as the graph isn’t that large on screen. If I change the size of the window then it does get slower, which again reinforces by guess at fill rate issues. A modern graphics card should be able to handle this so maybe the control is using software rendering. I'm not sure how I can prove that!!

So my OnRender method is pretty optimised as far as the logic goes. In both of the above cases the time it takes to draw, on the CPU, doesn't change much. However in some cases there is a terrible lag of around one second if a lot of pixels are touched.

Does anyone know how I could improve this?

One way I have considered is to render an off screen texture on another thread and once complete, then call InvalidateVisual once the texture has been updated. I could also do the invalidation every so often so the graph rendering updates over time, rather than just suddenly appears.

Anyone have experience of this sort of thing and how do I actually profile the internals of WPF?

Does anyone know a profiler that will show me what is actually causing this, but as I said I think it maybe down to the actually hardware render and a fill rate problem.

Just to note, my graph control inherits from Canvas and the line draw is done using StreamGeometryContext. I also freeze the geometry and all the brushes and pens.

Thanks

Answer 1

I write software that needs to graph large amounts of frequency sprectrum data very fast. WPF's retained graphics system isn't very good for drawing (graphing) large amounts of data that is changing frequently. We use D3D9 to draw our graphs. WPF provides a way to get this into their rendering system through the D3DImage class where it can become an ImageBrush. Thus, it avoids problems relating to airspace restrictions at the cost of a little performance, but will still be much faster than rendering with WPF objects.

There are also two very good graphing libraries that I have seen out there that have different pros/cons.

1. SciChart is actually a software based rendering charting tool for WPF but has good performance.
2. Lightning Chart Uses DirectX (Via SlimDX library which is a managed .NET wrapper) and is extremely performance oriented.

Regarding your question about software rendering... The WPF Performance Suite has profiling tools and overlays that can show which portions of your application are being software rendered. You may want to download it from Microsoft and give it a try.

From what I've read, WPF's rendering system is hardly optimal (A Critical Deep Dive into the WPF Rendering System). For what WPF is designed for, it is great, but it has its limits as well.

My recommendation is that if you have experience in game development and DirectX, and you need a method to graph larger amounts of data quickly, to look through interop with D3D via the D3DImage class in WPF.