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.
1. The composition thread was also introduced to Silverlight for the browser with Silverlight 5 but still lacks the autocaching capabilities present in Windows Phone. Autocaching is described in a moment.
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.
Although the composition thread frees the UI thread in some situations, the key to writing responsive apps is still making sure that the UI thread is not overloaded or blocked by user code—in event handlers, for example. If you anticipate that a particular section of code will tie up the UI thread for a considerable amount of time, for more than, say, 50 milliseconds, use a background thread to perform the activity. The web service APIs, for example, are all designed to be used asynchronously so that they do not block the UI thread.
The Windows Phone 8 SDK sees the inclusion of the new .NET async keyword that makes consuming asynchronous APIs far easier than it used to be.
If you are not familiar with the various mechanisms for spawning background threads, do not be concerned; you see many examples throughout the book.
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
Note
The composition thread is used only for scale transforms that are less than 50% of the original size. If the scale transform exceeds this amount, the UI thread performs the animation. In addition, the UIElement.Opacity and UIElement.Clip properties are handled by the composition thread. If an opacity mask or nonrectangular clip is used, however, the UI thread takes over.
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.