Optimize UI Elements and XAML Files for Graphics Performance (Compact 7)

3/12/2014

In Microsoft Expression Blend 3, the way that you design the UI in XAML files can affect the graphics performance when the UI elements are rendered on a display screen. For example, you can decide to use specific types of XAML elements that are optimized for hardware acceleration, or reorder XAML elements in a file and set z-order for optimal display buffer usage. Detailed information and a variety of recommended tasks for designing the UI in XAML files to optimize graphics performance are provided in the following paragraphs.

When you tune graphics performance for compact devices, you are trying to improve two major performance measurements in the UI.

• Load time (the time it takes to render the first screen), which depends on the following:
  • The number of UI elements in the design.
  • The types of UI elements in the design.
  • The visual design of the UI.
• Animation speed (the smooth and realistic appearance of movement on the screen), which depends on the following:
  • The number of UI elements that move.
  • The size of the UI elements that move, or the portion of the screen that is covered by moving elements.
  • Whether the UI elements are changing or oscillating as they move.

Using UI Elements in Your Application that are Optimized for Hardware Acceleration

Microsoft Silverlight for Windows Embedded includes UI elements that provide graphic effects that are optimized for hardware acceleration and that work better with the graphics renderer.

This section describes UI elements that are optimized for hardware acceleration.

Using Optimized UI Elements to Create Animations

Animating UI elements that are optimized for hardware acceleration can help improve animation frame rate.

To decide which UI elements to animate, use the UI elements in the following chart to achieve better graphics performance from animations.

Table 1: UI Elements Optimized for Animations

Effects based on the IXREffect class, such as the Blur and Drop Shadow effects, are also optimized for hardware acceleration. Both require a CPU that supports a pixel shader.

When deciding which UI elements to animate, note that the following are not optimized for hardware acceleration:

• LinearGradientBrush
• RadialGradientBrush
• GradientStop
• FrameworkElement.Margin

If multiple UI elements use the same type of animation for the same property, create a panel, such as a StackPanel, and move the UI elements into the panel element. Then, set the animation storyboard to animate the property in the parent element instead of in the multiple UI elements. For example, if three buttons all animate their Opacity property in the same way, you can move them into a StackPanel element and animate the Opacity property on the StackPanel instead of each button. For more information, see the "Group XAML Elements into a Panel Element" section in this document.

By animating a common property for multiple UI elements in their panel element, you can reduce the amount of rasterization operations required to play the animation, which helps improve animation frame rate.

To set the animation in a parent element in XAML

1. In your XAML file, identify multiple Storyboard elements that create the same animation, yet target different UI elements by using the Storyboard.TargetName attached property.

2. Move the UI elements into a StackPanel parent element.

3. Add the Storyboard element to the StackPanel parent element, and set its Storyboard.TargetProperty to a property of the StackPanel.

4. Delete the duplicate Storyboard elements.

Using Optimized UI Elements when you Display Images

A WriteableBitmap element is also not optimized for hardware acceleration when it is rendered at load time. To help improve load time, replace WriteableBitmap elements with BitmapSource elements, although you won’t be able to use the feature that modifies the bitmap’s pixels at run time.

UI elements that represent shapes and images that you don’t plan to animate, such as Path or Polygon elements, are also not optimized for hardware acceleration. To help improve load time, replace those elements with BitmapSource elements that have .bmp image files which display the same graphic as the UI element.

Using VisualState and ControlTemplate Elements

When you create animations for user controls, use VisualState elements to animate user controls when users change their state.

When you define the appearance of your controls, use reusable ControlTemplate elements instead of creating new XAML elements to define the appearance of each individual control.

Both of these elements represent on-demand parsed constructs, which can help improve graphics performance during load time.

Setting Bitmap Caching on UI Elements (Optional)

In Windows Embedded Compact 7, Silverlight for Windows Embedded provides default bitmap caching behavior by automatically setting bitmap caching for UI elements that should use hardware acceleration.

When UI elements that support bitmap caching are rendered on the screen, bitmaps for those elements are cached in memory so that they can be redrawn to the screen at a later time, which improves load time for that UI element.

However, if you have a Silverlight for Windows Embedded UI that has a significant number of graphic elements and a device with limited video memory, you should set bitmap caching explicitly on UI elements that should use hardware acceleration.

By setting bitmap caching explicitly, you can ensure that specific UI elements always use hardware acceleration, which helps improve graphics performance.

You should set the cache mode for all UI elements that implement animations or transformations.

To set bitmap caching for a XAML element in Silverlight for Windows Embedded, add a CacheMode attribute to the element and set its value to "BitmapCache."

The following example code sets bitmap caching for a Canvas element:

<Canvas Width="338" Height="400" Background="MidnightBlue" CacheMode="BitmapCache" >

Reordering XAML Elements and Setting Z-Order for Optimal Display Buffer Usage

The way that XAML elements are defined in XAML files can affect graphics performance of a Silverlight for Windows Embedded application when the elements are parsed and displayed on the device screen.

Changing the Order of XAML Elements

The default z-order, or the order in which elements are rendered on the screen, is based on the hierarchical order of elements in the XAML file.

Therefore, the order that you define elements in a XAML file implicitly determines both the z-order and the display buffer on which the XAML elements are grouped.

UI elements that use bitmap caching, such as animations, should be rendered first in the z-order. When these UI elements are rendered first, it reduces the amount of back-buffer surfaces that the system must create for other elements during the rendering process, which reduces graphics memory consumption.

To change the order of XAML elements

• Move UI elements that use bitmap caching toward the beginning of the XAML file.

Grouping XAML Elements into a Panel Element

Identify logical groups of UI elements that should be rendered on the screen together and place them inside a Panel element such as a Grid or Canvas. This can help improve load time for the group of UI elements.

For example, if you created a set of button elements that form a calculator on the main Canvas element, you can create a Canvas sub-element and move the button elements into that sub-element.

To group XAML elements into a Canvas

1. In your XAML file, define a Panel element, such as a Grid or Canvas, as a sub-element of the layout root Panel element.

2. Move the logical group of UI elements under that Panel element, so that they are sub-elements of that Panel element.

Grouping XAML Elements into User Controls

If you plan to display the logical group of elements in several windows, or in several different Silverlight for Windows Embedded applications, add the group of elements to a custom user control. This can help improve load time for the group of UI elements.

By adding the elements to a custom user control, you can reuse the elements and their functionality without writing additional code for each window or application.

Separating XAML into Several Smaller Files

At run time, when Silverlight for Windows Embedded periodically loads smaller XAML files instead of one large XAML file when the application starts, it reduces the workload of the XAML parser to parse and load each page or each control, which can help improve load time.

To separate XAML into several smaller files

1. Move XAML elements that are displayed in a single window in your application into separate .xaml files.

2. Move logical groups of XAML elements displayed in windows in your application into separate .xaml files.

3. In your C++ application code, call IXRApplication::ParseXaml to load the individual .xaml files only when the application will display the elements in that XAML file.

Setting the Z-Order on UI Elements

To ensure that a specific XAML element is always rendered higher in the z-order than another XAML element, you can set the z-order directly for both elements. Note that UI elements that use bitmap caching, such as animations, should be rendered first in the z-order.

To explicitly set z-order on a XAML element

1. Add a Canvas.ZIndex attached property to the UI element.

2. To render the UI element first, set the Canvas.ZIndex value to a higher number. For example, set it to "5."

3. To render the UI element after another element, set the Canvas.ZIndex value to a lower number. For example, set it to "1."

Removing Unnecessary XAML Elements

To help improve graphics performance, identify and remove unnecessary XAML elements. With fewer XAML elements in the visual tree, the application can load the visual tree more quickly.

If you have a visual tree with a large number of XAML elements, and you are experiencing issues with graphics performance, reevaluate the UI elements in your XAML files, and identify XAML elements that are not essential to the functionality of the application (such as decorative UI elements that do not handle UI events and that do not support user interaction). Then, remove nonessential XAML elements (such as decorative background shapes or geometries).

During the design phase, the designer might replace XAML elements with other XAML elements and forget to delete the unused XAML elements, which are lower in the z-order and are obscured by elements higher in the z-order. Or, the designer might add and then decide not to use elements that are invisible, yet are still defined in the XAML file (such as shape elements with a transparent background color, or text boxes with no text). You should identify and delete any unused XAML elements in your Expression Blend project that are present in XAML View, yet are no longer displayed in Design View.

Using a VirtualizingStackPanel (Optional)

If you use ItemsControl elements in your Silverlight for Windows Embedded UI, such as a ListBox or ComboBox, you should also use a VirtualizingStackPanel.

With a VirtualizingStackPanel, Silverlight for Windows Embedded renders only the elements in the items control that are currently visible. By using a VirtualizingStackPanel, you can help improve load time for the items in the items control.

To use a VirtualizingStackPanel

1. Add the VirtualizingStackPanel.IsVirtualizing attached property to the ItemsControl element.

2. Set the attached property value to True.

To reuse item containers after they are no longer visible on the screen

1. Add the VirtualizingStackPanel.VirtualizationMode attached property to the UI element.

2. Set the attached property value to Recycling.

The following example code shows a list box element that uses a VirtualizingStackPanel.

<ListBox x:Name="listbox" Width="200"  Height="150" VirtualizingStackPanel.IsVirtualizing="True">

Setting the TargetType for ControlTemplate and Style Elements

If you use a ControlTemplate or Style element in the XAML for a Silverlight for Windows Embedded application, you must explicitly set the ControlTemplate.TargetType or Style.TargetType attribute value.

Silverlight for Windows Embedded internally compiles your XAML files into binary format, known as Binary XAML (BAML). By using BAML, applications don’t have to parse XAML files each time that the application starts, which reduces load time and can help improve graphics performance.

Silverlight for Windows Embedded uses algorithms to compile XAML into BAML. When Silverlight for Windows Embedded compiles ControlTemplate and Style elements into BAML, if it cannot determine the type of control for the template or style, it does not compile the template or style into binary format. Therefore, you must always set the TargetType XAML attribute.

To set the TargetType XAML attribute

1. In your XAML files, add a TargetType attribute to every Style and ControlTemplate element.

2. Set the TargetType attribute value to the name of the element to which you want to apply the template or style.

   If the element is a custom user control, set the TargetType attribute value to the name of the custom user control prefixed with its XAML namespace.

The following example code shows a Style element with the TargetType set to a Button element.

<Style x:Key="ButtonStyle1" TargetType="Button">

See Also

Concepts

Graphics and Performance in Silverlight for Windows Embedded