Following are some of the performance data that can be focused by WPF application developers so as to improve performance.

Planning for Application Performance

You must develop a performance strategy before you start developing any WPF application. You must draft out the scenarios where the performance plays a vital factor. Application start-up time, Per-frame animation frequency rate, maximum working set allowed in a window etc, are some of the scenarios you could plan and strategise well before.

Once you come up with the scenarios, you can define goals and measure, investigate, refine performance of your application on a cyclic/iterative basis.

Taking Advantage of Hardware

WPF supports both the Software and Hardware rendering pipelines.

a)      Software rendering is totally CPU dependent – more pixels you wants to render, greater the cost. As a developer, you may reduce the redrawing of pixels on main components such as background, transparency etc.

b)      Hardware rendering allows you to offload the rendering to the Graphics Processing Unit (GPU) fully utilizing the Microsoft’s DirectX v 7.0 or later and Pixel Shader 2.0+ features. WPF has an API that determines the rendering tier (0, 1, and 2) required for a specific hardware to accelerate the performance.

Layout and Design

a)      Avoid un-necessary changes in the layout. A slightest change in a position of a control would invoke a process called “Layout Pass” that measures and arranges the controls in a Panel derived containers.

b)      Choose the right panel; Stack Panel and Grid provides more functionalities than a Canvas.

c)       Whenever required, while performing Transform, do the updates for the properties, in place of replacing the whole transform as it costs more for designing the layout once again.

d)      A Top-Down tree like hierarchical pattern of child elements in a DockPanel or TextBlock should be followed so as to ensure the right validations.

2D Graphics and Imaging

a)      Graphical drawing content has its own performance factors. Drawing objects are simpler constructs than Shape objects and provide better performance characteristics. Shape objects are derived from FrameworkElement class and can be used inside Panel and other controls. But Drawing objects are not derived from FrameworkElement class and provides a lighter-weight implementation for rendering shapes, images, and text.

b)      The DrawingVisual object is a lightweight drawing class that is used to render shapes, images, or text and does not provide layout or event handling, thus improving performance.

c)       You can reduce the application working set and gain execution speed by requesting WPF to decode your image to desired size or thumbnail size rather than to default size. 

d)      When animating the scale of any bitmap, the default high-quality image re-sampling algorithm can sometimes consume sufficient system resources to cause frame rate degradation, effectively causing animations to stutter. By setting the BitmapScalingMode property of the RenderOptions object to LowQuality you can create a smoother animation when scaling a bitmap.

e)      By default, WPF does not cache the rendered contents of TileBrush objects, such as DrawingBrush and VisualBrush. By setting the CachingHint property of the RenderOptions object to Cache you can increase performance by using cached versions of the tiled brush objects.

Object Behavior

a)      When performing clean up of an object that has registered to listen to an object's event, it is essential to remove the associated event handler delegates before releasing the object.

b)      Accessing a dependency property of a DependencyObject is faster  than accessing a CLR property. Furthermore, dependency properties support robust features, such as data binding, animation, inheritance, and styling.

c)       Explicitly converting a dependency property inheritable will impact the performance as it increases the length of time for property invalidation.

d)      Freezing objects whenever possible improves the performance of your application and reduces its working set. Also, it no longer needs to expend resources on maintaining change notifications. You may call the Freeze method or set the Freezable property on a SolidColorBrush that signifies the performance.

e)      It is intensive, both in terms of memory and processor, to generate a large number of UI elements within a StackPanel when only a few may be on the screen at a given time. As a performance optimization, you may use the VirtualizingStackPanel control so that visual objects for these items are generated or kept alive only if they are visible on the screen.

Application Resources

a)      It is recommended that you either define the resources at the Application or Window object level, or define them in the default theme for the custom controls for the purpose of providing a consistent look or behavior across similar-typed elements.

b)      If you have multiple elements using the same Brush object, define the brush as a resource and reference it, rather than defining the brush inline in XAML.

c)       Use static resources whenever possible in your application, using dynamic resources only when necessary.  Lookup behavior for static resource is analogous to compile-time lookup where as for the dynamic resource is to run-time lookup that imposes a performance impact.

Text

a)      Rendering Text at the Glyph Level allows you to intercept and persist text after formatting and can be used only for fixed-format document presentation and print scenarios.  Screen display of fixed-format documents, using XAML as a device printer language, Microsoft XPS Document Writer, Compatibility with earlier versions of printer driver, Print spool format are some of the scenarios you may use it for.

b)      The TextBlock element should be used when limited text support is required, such as a brief sentence in a user interface (UI). Label can be used when minimal text support is required. The FlowDocument element is a container for re-flowable documents that support rich presentation of content, and therefore, has a greater performance impact than using the TextBlock or Label controls.

c)       Avoid using TextBlock in FlowDocument.  When possible, use Run(derived from TextElement) rather than TextBlock(derived from UIElement)  for displaying text content in a FlowDocument.

d)      Avoid Databinding to the Label.Content Property. When data binding the Label element's Content property to the String source object, you may experience poor performance. Each time the source String is updated, the old String object is discarded and a new String is recreated—because a String object is immutable, it cannot be modified.

e)      You can optimize the use of multiple Hyperlink elements by grouping them together within the same TextBlock. This helps to minimize the number of objects you create in your application.

Data Binding

a)      Data Binding to Dependency Properties/objects are much faster than CLR Properties/objects as the latter requires Data Binding Engine to use reflection to resolve object references.

b)      There is a significant performance impact when you data bind to a single CLR object with thousands of properties. You can minimize this impact by dividing the single object into multiple CLR objects with fewer properties.

c)       Employing a correspondence between a CLR List<(Of <(T>)>) object that to display items in a ListBox requires binding data to the ItemsSource property of the ListBox.  However, updates and inserts to the ListBox will not raise the CollectionChanged  event automatically to reflect the changes smoothly by the data binding engine. To resolve this problem, you must make the List object an ObservableCollection<(Of <(T>)>) to raise change notifications automatically.

d)      If you have a choice between binding an IList<(Of <(T>)>) and an IEnumerable to an ItemsControl object, choose the IList<(Of <(T>)>) object as the latter implicitly create the IList anyway.

e)      Data binding to XML content is slower than data binding to CLR objects. Do not convert CLR object data to XML if the only purpose is for data binding.

Better Practices

When you use a Brush to set the Fill or Stroke of an element, it is better to set the Brush.Opacity value rather than the setting the element's Opacity property. Modifying an element's Opacity property can cause WPF to create a temporary surface.

When you use the NavigationWindow object, you will need to keep in mind how the journaling support impacts your application's performance. When you navigate using a uniform resource identifier (URI), only the uniform resource identifier (URI) reference is stored in the journal. And, each time you revisit the page, it is dynamically reconstructed.  In this case, the journal storage cost is low, but the time to reconstitute the page is potentially high. When you navigate using an object, the journal stores the entire visual tree of the object. And, each time you revisit the page, it renders immediately without having to be reconstructed. In this case, the journal storage cost is high, but the time to reconstitute the page is low.

Hit testing on large 3D surfaces, especially when it is animating, is a very performance intensive operation in terms of CPU consumption. Disabling Hit testing is the preferred way.

Whenever possible, avoid using the ScrollBarVisibility.Auto value for RichTextBox, ScrollViewer, and TextBox objects etc.

The WPF Font Cache service shares font data between WPF applications. The first WPF application you run starts this service if the service is not already running. If you are using Windows Vista, you can set the "Windows Presentation Foundation (WPF) Font Cache 3.0.0.0" service from "Manual" (the default) to "Automatic (Delayed Start)" to reduce the initial start-up time of WPF applications.