Are you a WPF developer? Do your WPF apps have areas of poor performance or don\u2019t run as quickly as you would like? If so, I have 15 <\/b>tips to help you identify and improve the performance of your WPF applications. <\/p>\n\n\n\n
While WPF is over a decade old and has been improved greatly over the years, there are still several areas that can suffer from poor performance. The reasons for this poor performance include things such as bad coding practices, broken bindings, complex layouts, the lack of UI virtualization, and much more. Luckily, with a little planning and a solid understanding of the WPF platform, you can have your WPF apps jumping into warp speed and leaping across the universe in milliseconds. <\/p>\n\n\n\n
I have put together these 15 tips to help you improve the performance of your WPF apps.<\/p>\n\n\n\n
A common source of performance issues is a deep and complex layout. Keep your XAML markup as simple and shallow as possible. <\/span><\/span>When UI elements are drawn onscreen, a \u201clayout pass\u201d is called twice for each element (a measure pass and an arrange pass). The<\/span><\/span> layout pass is a mathematically-intensive process\u2014the larger the number of <\/span><\/span>children<\/span><\/span> in the <\/span><\/span>element<\/span><\/span>, the greater the number of calculations required<\/span><\/span>.<\/span><\/span> <\/span><\/span> <\/span><\/p>\n\n\n\n As mentioned earlier, a complex and deep visual tree results in a larger memory footprint and slower performance. ItemsControls usually increase performance problems with deep visual trees because they are not virtualized. This means they are constantly being created and destroyed for each item in the control. Instead, use the VirtualizingStackPanel as the items host and make use of the VirtualizingStackPanel.IsVirtualizing and set the VirtualizationMode to Recycling in order to reuse item containers instead of creating new ones each time. StaticResources provide values for any XAML property attribute by looking up a reference to an already defined resource. Lookup behavior for that resource is the same as a compile-time lookup. DynamicResources will create a temporary expression and defer lookup for resources until the requested resource value is required. Lookup behavior for that resource is the same as a run-time lookup, which imposes a performance impact. Always use a StaticResource whenever possible. If you use a Brush to set the Fill or Stroke of an element, it is better to set the Opacity on the Brush rather than setting the element\u2019s Opacity property. When you modify an element\u2019s Opacity property, it can cause WPF to create temporary surfaces which results in a performance hit. Avoid using Runs within a TextBlock as this results in a much higher performance intensive operation. If you are using a Run to set text properties, set those directly on the TextBlock instead. The StreamGeometry object is a very light-weight alternative to a PathGeometry. StreamGeometry is optimized for handling many PathGeometry objects. It consumes less memory and performs much better when compared to using many PathGeometry objects. If your app requires the display of smaller thumbnails, consider creating reduced-sized versions of your images. By default, WPF will load and decode your image to its full size. This can be the source of many performance problems if you are loading full images and scaling them down to thumbnail sizes in controls such as an ItemsControl. If possible, combine all images into a single image, such as a film strip composed of multiple images. By default, WPF uses a high-quality image re-sampling algorithm that can sometimes consume system resources which results in frame rate degradation and causes animations to stutter. Instead, set the BitMapScalingMode to LowQuality to switch from a \u201cquality-optimized\u201d algorithm to a \u201cspeed-optimized\u201d algorithm. A Freezable is a special type of object that has two states: unfrozen and frozen. When you freeze an object such as a Brush or Geometry, it can no longer be modified. Freezing objects whenever possible improves the performance of your application and reduces its memory consumption. Binding errors are the most common type of performance problem in WPF apps. Every time a binding error occurs, your app takes a perf hit and as it tries to resolve the binding and writes the error out to the trace log. As you can imagine, the more binding errors you have the bigger the performance hit your app will take. Take the time to find and fix all your binding errors. Using a RelativeSource binding in DataTemplates is a major culprit in binding error as the binding is usually not resolved properly until the DataTempate has completed its initialization. Avoid using RelativeSource.FindAncestor at all costs. Instead, define an attached property and use property inheritance to push values down the visual tree instead of looking up the visual tree. If you are using a Label to data bind to a String property, this will result in poor performance. This is because each time the String source is updated, the old string object is discarded, and a new String is created. If the Content of the Label is simple text, replace it with a TextBlock and bind to the Text property instead. When data binding an ItemsControl to an IEnumerable, WPF will create a wrapper of type IList<T> which negatively impacts performance with the creation of a second object. Instead, bind the ItemsControl directly to an IList to avoid the overhead of the wrapper object. Use the NeutralResourcesLanguageAttribute to tell the ResourceManager what the neutral culture is and avoid unsuccessful satellite assembly lookups. A very common source of performance problems, UI freezes, and apps that stop responding is how you load your data. Make sure you are asynchronously loading your data on a separate thread as to not overload the UI thread. Loading data on the UI thread will result in very poor performance and an overall bad end-user experience. Multi-threading should be something every WPF developer is using in their applications. Memory leaks are the number one cause of performance problems in most WPF applications. They are easy to have but can be difficult to find. For example, using the DependencyPropertyDescriptor.AddValueChanged can cause the WPF framework to take a strong reference to the source of the event that isn\u2019t removed until you manually call DependencyPropertyDescriptor.RemoveValueChanged. If your views or behaviors rely on events being raised from an object or ViewModel (such as INotifyPropertyChanged), subscribe to them weakly or make sure you are manually unsubscribing. Also, if you are binding to properties in a ViewModel which does not implement INotifyPropertyChanged, chances are you have a memory leak. <\/span><\/p>\n\n\n\n Finally, a bonus tip. Sometimes when you have a performance problem it can be very difficult to identify what exactly is causing the issue. I suggest using an application performance profiler to help identify where these performance bottle necks are occurring in your code base. There are a lot of profiler options available to you. Some are paid, and some are free. The one I personally use the most is the Diagnosis Tools <\/a>built directly into Visual Studio 2019.<\/span><\/p>\n\n\n\n Be sure to engage with me on Twitter<\/a>, subscribe to my YouTube channel<\/a> to be notified of new video content, and follow me on Twitch<\/a> to watch me stream live. And if you are using Ultimate UI for WPF<\/a>, be sure to connect with our various teams via our Community Forums<\/a> where you can interact with Infragistics engineers and other customers. <\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Are you a WPF developer? Here we present 15 tips to help you identify and improve the performance of your WPF applications. Read more.<\/p>\n","protected":false},"author":43,"featured_media":1150,"comment_status":"publish","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":["post-834","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wpf"],"_links":{"self":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/834","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/users\/43"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/comments?post=834"}],"version-history":[{"count":14,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/834\/revisions"}],"predecessor-version":[{"id":1878,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/posts\/834\/revisions\/1878"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media\/1150"}],"wp:attachment":[{"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/media?parent=834"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/categories?post=834"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infragistics.com\/blogs\/wp-json\/wp\/v2\/tags?post=834"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Virtualize your ItemsControls<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n3. Favor StaticResources over DynamicResources<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n4. Opacity on Brushes Instead of Elements<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n5. Avoid Using Run to Set Text Properties<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n6. Favor StreamGeometries over PathGeometries<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n7. Use Reduced Image Sizes<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n8. Lower the BitMapScalingMode<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n9. Use and Freeze Freezables<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n10. Fix your Binding Errors<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n11. Avoid Databinding to the Label.Content Property<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n12. Bind ItemsControls to IList instead of IEnumerable<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n13. Use the NeutralResourcesLanguage Attribute<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n14. Load Data on Separate Threads<\/h2>\n\n\n\n
<\/span><\/p>\n\n\n\n15. Beware of Memory Leaks<\/h2>\n\n\n\n