- Understanding the Role of XAP Files
- The Windows Phone Capabilities Model
- The Threading Model for XAML-Based Graphics and Animation in Windows Phone
- Understanding the Frame Rate Counter
- The Windows Phone Application Analysis Tool
- Reading Device Information
- Applying the Model-View-ViewModel Pattern to a Windows Phone App
- Property Change Notification
- Using Commands
- Argument Validation
- A Platform-Agnostic Dialog Service
- Consuming Local Web Applications
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Threading Model for XAML-Based Graphics and Animation in Windows Phone
XAML apps use two threads for graphics and animation: a UI thread and a composition thread. The composition thread was introduced with the second release (7.5) of the Windows Phone OS. The first release of the OS had issues with performance around user input. A single UI thread had been largely acceptable for Silverlight for the desktop and browser because both generally rely on the mouse for input. The phone, however, relies on touch, which, as it turned out, needs to be substantially more reactive to user input. When using a mouse, a slight delay does not unduly affect the user’s perception of your app, but when using touch, a slight delay can make the user feel like the device is broken. Thus, the composition thread was introduced in Windows Phone 7.51 to assist in rendering visuals by offloading some of the work traditionally done by the UI thread.
The UI thread is the main thread in Windows Phone XAML apps and handles user input, events, parsing, and creation of objects from XAML, and the initial drawing of all visuals.
The composition thread aides the UI thread in handling graphics and animation, freeing up the UI thread and making it more responsive to user input. Storyboard-driven animations that run on the composition thread are cached and handled by the device GPU in a process called autocaching.
The composition thread is used for animations involving the UIElement’s RenderTransform and Projection properties. Typically these animations include the following from the System.Windows.Media namespace:
- PlaneProjection
- RotateTransform
- ScaleTransform
- TranslateTransform
Animations and Threads
The composition thread is ideal for handling storyboard animations because it is able to pass them to the device GPU for processing, even while the UI thread is busy. Code-driven animations, however, do not benefit from the composition thread because these kinds of animations are handled exclusively by the UI thread, frame by frame using a callback. They are, therefore, subject to slowdown depending on what else occupies the UI thread, and the animation will update only as fast as the frame rate of the UI thread.
Performance and Element Visibility
XAML-based apps provide two properties that allow you to hide or reveal UI elements: UIElement.Visibility and UIElement.Opacity—each of which has performance implications depending on how it is used.
The UIElement.Visibility property is handled by the UI thread. When an element’s Visibility property is set to Collapsed, the visual tree must be redrawn. The upside is that when collapsed, the UIElement is not retained in visual memory, and thus decreases the amount of memory used by your app.
Conversely, controlling the visibility of an element using the UIElement.Opacity property allows the element to be bitmap cached; the element is stored as a simple bitmap image after the first render pass. Bitmap caching allows the rendering system to bypass the render phase for the cached element and to use the composition thread to display the bitmap instead, which can free up the UI thread considerably. By setting the opacity of a cached element to zero, you hide the element without requiring it to be redrawn later. This, however, does mean that unlike the Visibility property, the element is still retained in visual memory.
Deciding Between Visibility and Opacity
Element opacity in conjunction with bitmap caching usually produces the best performance when hiding and revealing elements. There may be times, however, when the UIElement.Visibility property is better, and this is influenced by the number and complexity of the visual elements being rendered. In such cases it may require experimentation to determine the best approach.