Is this slow WPF TextBlock performance expected?

Question

I am doing some benchmarking to determine if I can use WPF for a new product. However, early performance results are disappointing. I made a quick app that uses data bindi

Answer 1

I would only use WPF for a new product if you are certain your deployment hardware is quite good. Practically speaking, I think a dedicated graphics card is a minimum requirement.

My team selected WPF for a project targeted at an Atom processor platform because the integrated GMA 500 graphics claimed WPF render Tier 2. However, for some reason the performance of the GMA 500 is very slow and we turned hardware rendering off to get better performance. Even then, the Atom platform is underpowered for reasonable performance. I advise not using WPF if netbooks or anything with Intel Atom is part of your customer base.

Here is a link to a question I have open on the performance of WPF on GMA 500.

As Rob Perkins suggests, you may be better off with Silverlight 4 for better performance.

Good luck!

Answer 2

Is this slow TextBlock performance normal?

No. Such slow TextBlock performance is definitely not normal. My experience has been TextBlocks are much faster than that.

I ran several tests using the code you posted, leaving the update interval at 0.1s and varying the hardware and number of TextBlocks. Here is what I found:

 10 TextBlocks, 2.16GHz Core 2 Duo, Radeon 4100 GPU:     CPU Usage "0%"
 10 TextBlocks, 2.16GHz Core 2 Duo, Software rendering:  CPU Usage 1%
100 TextBlocks, 2.16GHz Core 2 Duo, Radeon 4100 GPU:     CPU Usage 8%
100 TextBlocks, 2.16GHz Core 2 Duo, Software rendering:  CPU Usage 18%
 10 TextBlocks, 200MHz Pentium Pro, Software rendering:  CPU Usage 35%
 10 TextBlocks, 200MHz Pentium Pro, No rendering:        CPU Usage 7%

Every one of these tests suggests that WPF is approximately 10x as fast as your measurements indicate. If your code is as simple as it appears, my suspicion would be that there is something strange going in with your GPU or DirectX drivers.

Note that for the 100 TextBlock tests I had to make three changes: Adding 90 TextBlocks, setting the ItemsPanel to a WrapPanel to get the data in columns, and reducing the TextBlock width to get everything to fit on screen.

My test on the 200MHz Pentium Pro is probably the most relevant to your embedded hardware. If your application updates 10 TextBlocks every 0.5s you can expect to use approximately 3% of the CPU for the update and redraw on a 200MHz CPU.

What if I want to make it even faster?

Using a list of data-bound TextBlocks is very convenient but WPF also provides lower-level mechanisms that can be used when you need absolute maximum performance.

A WPF TextBlock actually contains a formatted document not just a string, so it is a very complex data structure. It is quite simple to write your own TrivialTextBlock control which has a string parameter and simply draws it using the inherited TextElement properties (such as FontSize, FontWeight, etc). This is usually not done because TextBlock is fast enough for almost all purposes.

Another consideration is that every time you change the text in a TextBlock, WPF recomputes the layout. Unlike older technologies, the content of a WPF TextBlock can very easily change the layout of your UI. So the text must be remeasured and reformatted every time you change it. Creating the aforementioned TrivialTextBlock control can speed this up as well by fixing the control size and thereby avoiding layout passes.

A third consideration is that WPF's text formatter has advanced typography features, supporting such things as kerning, bidirectional text, ligatures, unicode features, custom font weights, etc. To get absolute maximum performance in WPF you can bypass the text formatter entirely and draw your text as a series of images. This requires about 20 lines of XAML and about 40 lines of C# code.

All of these optimizations are possible, but in your case I wouldn't bother with them: Doing it to save a mere 3% CPU usage is probably not worth it.

Answer 3

There is a lot one can do wrong in WPF, as far as performance is concerned. Lot of people approach it like a win forms application, html web page, or some hybrid attack on developing the application and because of this there are a lot of bad evaluations of WPF.

I understand that you are trying to do performance testing to see if a WPF can work for your platform and a good example of how to get your WPF application control to perform for the type of load you are expecting can be found at the below link.

http://msdn.microsoft.com/en-us/magazine/dd483292.aspx

Petzold guides you through the process of optimizing an items control to render optimally for the load of data being displayed on the UI.

To do a fair test I would write a sample application that deals with a sample of the data you are going to be dealing with, and then test the performance of that code. There are a large number of optimizations that can be applied to make a WPF application scream and use less CPU, but they all depend on your application and how it is representing your data.

Hope this helps.