WPF Performance Tuning Experience Summary

WPF performance Optimization One, Rendering Tier

1. Depending on the hardware configuration, WPF renders with different rendering tiers. Pay special attention to the following situations, because in these cases there is no hardware acceleration even in the case of rendering Tier 2. (Incomplete, check the SDK for the rest)

WPF performance Optimization II, layout and design

1. Use simple layout elements such as canvas, use less grid or StackPanel, and more complex performance overhead.

2. When establishing a logical tree or a visual tree, follow the top-down principle.

WPF performance Optimization three, image

1. When animating the image (such as resizing, etc.), you can use this statement renderoptions.setbitmapscalingmode (myimage,bitmapscalingmode.lowquality) to improve performance.

2. When using TileBrush, you can cachinghint.

WPF performance Optimization Four, object behavior

1. Accessing CLR objects and CLR properties is much more efficient than accessing dependencyobject/dependencyproperty. Note that this refers to access, not to be confused with the previous bindings. However, registering a property as DependencyProperty has many advantages: inheritance, data binding, and style.

WPF Performance Optimization v. Application resources

1. In a custom control, try not to define resources in the resourcedictionary of the control, but at the window or application level. Because placing in the control causes each instance to retain a copy of the resource.

2. Use static Resources as much as possible, but not blindly.

WPF performance Optimization VI, text

1. When the text is small, use TextBlock or label, long time with FlowDocument.

2. When using elements TextFlow and TextBlock, you should consider using TextBlock if you do not need some of the features of TextFlow, because it is more efficient.

3. The cost of using UIElement (such as TextBlock) in TextFlow is higher than the cost of using textelement (such as run). Avoid using FlowDocument in TextBlock and use Run instead.

4. Explicitly using the Run command in TextBlock is higher than code that is not named with Run.
5. Binding the Contentproperty of a LABEL element to a string (string) is less efficient than binding the string and TextBlock's Text property. Because the label updates the string, it discards the original string, and all the content is re-displayed. If the string does not need to be updated, the label does not matter for performance.

6. When using hyperlinks in TextBlock blocks, it is more efficient to combine multiple hyperlinks together.

7. When displaying hyperlinks, try to display underscores only when IsMouseOver is true, and the code that always displays underscores is much higher

8. Try not to use unnecessary string connections.

WPF performance optimization Vii. data binding

1. In the process of using data binding, if the bound data source is a CLR object, and the property is also a CLR property, then the object CLR object implements a different mechanism when binding, and the binding is more efficient.

A, the data source is a CLR object, and the property is also a CLR property. The Typedescriptor/propertychanged object implements the notification function through the mode. The binding engine now uses TypeDescriptor to reflect the source object. Lowest efficiency.

B, the data source is a CLR object, and the property is also a CLR property. The INotifyPropertyChanged object implements the notification function through the. The binding engine now reflects the source object directly. Slightly more efficient.

C, the data source is a dependencyobject, and the attribute is a DependencyProperty. There is no need for reflection at this time, direct binding. Most efficient.

2. When a CLR object is large, such as having 1000 attributes, try to break the object down into many small CLR objects. For example, a CLR object that is divided into 1000 only one property.

3. When we display a list of CLR objects (such as list) in a list (such as a ListBox), the ListBox also dynamically reflects this change if you want to modify the list object. At this point, we should use a dynamic ObservableCollection object binding. Instead of updating Itemsource directly. The difference between the two is that updating itemsource directly causes WPF to discard all the data that is already in the listbox and then reload all of it from the list. The use of ObservableCollection can avoid this process of removing and reloading all the first, and is more efficient.

4. Try to bind IList instead of IEnumerable to ItemsControl.

WPF performance Optimizations Eight, other performance recommendations

1. If you need to modify the opacity property of an element, finally modify the property of a brush and then fill the element with this brush. Because modifying the opacity of an element directly forces the system to create a temporary surface

2. When using NavigationWindow, try to update the client area by object instead of the URI

3. Try not to use Scrollbarvisibility=auto

WPF performance Optimization One, Rendering Tier

1. Depending on the hardware configuration, WPF renders with different rendering tiers. Pay special attention to the following situations, because in these cases there is no hardware acceleration even in the case of rendering Tier 2. (Incomplete, check the SDK for the rest)

WPF performance Optimization II, layout and design

1. Use simple layout elements such as canvas, use less grid or StackPanel, and more complex performance overhead.

2. When establishing a logical tree or a visual tree, follow the top-down principle.

WPF performance Optimization three, image

1. When animating the image (such as resizing, etc.), you can use this statement renderoptions.setbitmapscalingmode (myimage,bitmapscalingmode.lowquality) to improve performance.

2. When using TileBrush, you can cachinghint.

WPF performance Optimization Four, object behavior

1. Accessing CLR objects and CLR properties is much more efficient than accessing dependencyobject/dependencyproperty. Note that this refers to access, not to be confused with the previous bindings. However, registering a property as DependencyProperty has many advantages: inheritance, data binding, and style.

WPF Performance Optimization v. Application resources

1. In a custom control, try not to define resources in the resourcedictionary of the control, but at the window or application level. Because placing in the control causes each instance to retain a copy of the resource.

2. Use static Resources as much as possible, but not blindly.

WPF performance Optimization VI, text

1. When the text is small, use TextBlock or label, long time with FlowDocument.

2. When using elements TextFlow and TextBlock, you should consider using TextBlock if you do not need some of the features of TextFlow, because it is more efficient.

3. The cost of using UIElement (such as TextBlock) in TextFlow is higher than the cost of using textelement (such as run). Avoid using FlowDocument in TextBlock and use Run instead.

4. Explicitly using the Run command in TextBlock is higher than code that is not named with Run.
5. Binding the Contentproperty of a LABEL element to a string (string) is less efficient than binding the string and TextBlock's Text property. Because the label updates the string, it discards the original string, and all the content is re-displayed. If the string does not need to be updated, the label does not matter for performance.

6. When using hyperlinks in TextBlock blocks, it is more efficient to combine multiple hyperlinks together.

7. When displaying hyperlinks, try to display underscores only when IsMouseOver is true, and the code that always displays underscores is much higher

8. Try not to use unnecessary string connections.

WPF performance optimization Vii. data binding

1. In the process of using data binding, if the bound data source is a CLR object, and the property is also a CLR property, then the object CLR object implements a different mechanism when binding, and the binding is more efficient.

A, the data source is a CLR object, and the property is also a CLR property. The Typedescriptor/propertychanged object implements the notification function through the mode. The binding engine now uses TypeDescriptor to reflect the source object. Lowest efficiency.

B, the data source is a CLR object, and the property is also a CLR property. The INotifyPropertyChanged object implements the notification function through the. The binding engine now reflects the source object directly. Slightly more efficient.

C, the data source is a dependencyobject, and the attribute is a DependencyProperty. There is no need for reflection at this time, direct binding. Most efficient.

2. When a CLR object is large, such as having 1000 attributes, try to break the object down into many small CLR objects. For example, a CLR object that is divided into 1000 only one property.

3. When we display a list of CLR objects (such as list) in a list (such as a ListBox), the ListBox also dynamically reflects this change if you want to modify the list object. At this point, we should use a dynamic ObservableCollection object binding. Instead of updating Itemsource directly. The difference between the two is that updating itemsource directly causes WPF to discard all the data that is already in the listbox and then reload all of it from the list. The use of ObservableCollection can avoid this process of removing and reloading all the first, and is more efficient.

4. Try to bind IList instead of IEnumerable to ItemsControl.

WPF performance Optimizations Eight, other performance recommendations

1. If you need to modify the opacity property of an element, finally modify the property of a brush and then fill the element with this brush. Because modifying the opacity of an element directly forces the system to create a temporary surface

2. When using NavigationWindow, try to update the client area by object instead of the URI

3. Try not to use Scrollbarvisibility=auto

WPF Performance Tuning Experience Summary