Performance Tips for Silverlight-based Applications
This overview provides tips to ensure that your Microsoft Silverlight-based applications run fast and smoothly.
This topic contains the following sections:
- Test on Multiple Platforms and Browsers
- Set EnableFrameRateCounter to true During Development
- Use Transparent Background for a Silverlight Plug-in Sparingly
- Use Silverlight Animations Instead of Creating Your Own Per-Frame Animations
- Avoid Animating the Size of Text
- Avoid Using Windowless Mode
- Use Visibility Instead of Opacity Whenever Possible
- Silverlight Uses Multi-Core in Rendering and Media
- In Full-Screen Mode, Hide Unused Objects
- Do Not Use Width and Height with MediaElement Objects
- Do Not Use Width and Height with Path Objects
- When Downloader Finishes, Detach Events and Set to Null
- Break Up CPU-Intensive Work into Smaller Tasks
Test on Multiple Platforms and Browsers
If you are developing Silverlight-based applications for multiple operating systems (for example, Macintosh and Windows) and browsers (for example, Microsoft Internet Explorer, Mozilla FireFox, and Apple Safari), remember to routinely test your applications by using the platform and browser combinations that you are targeting. The differences in platform or browser behavior, and the code Silverlight uses to handle the behavior, can affect application performance. In particular, you should test thoroughly when you create applications that have transparent embedded plug-in backgrounds, or applications that use a large amount of JavaScript code.
Set EnableFrameRateCounter to true During Development
The rendering performance of the plug-in varies with the hosting parameters that are specified and the complexity of the content. We recommend that you set the EnableFrameRateCounter property to true during development. This setting will display the frames-per-second (fps) of the rendered Silverlight content in the browser's status bar, so you can fine-tune your application. The format of the framerate counter is as follows:
fps:currentFramerate/maxFramerate
currentFramerate is the optimal framerate that would apply in absence of an upper framerate limit, based on conditions of the plug-in's environment and reported by the plug-in. maxFramerate is configurable, via the framerate initialization parameter (see Instantiating a Silverlight Plug-in). maxFramerate defaults to 24. Each of these numbers is a value reporting frames per second (fps). These values are interpreted to mean that whichever number is lower is the actual displayed frame rate. You can illustrate this relationship between currentFramerate and maxFramerate and by setting a deliberately low frame rate such as 2 per second and observing the results.
Use Transparent Background for a Silverlight Plug-in Sparingly
A transparent background may be useful, for example, when your embedded Silverlight plug-in contains a non-rectangular shape such as a picture of a car, and you do not want to show the rectangle surrounding the car. You can make only the picture of the car visible by setting the background of the Silverlight plug-in to transparent. However, using a transparent background for a Silverlight plug-in has a significant effect on performance, so avoid using this functionality whenever possible.
Use Silverlight Animations Instead of Creating Your Own Per-Frame Animations
It is faster to change property values by using Silverlight built-in animations instead of creating your own per-frame animations using JavaScript. The recommended method for manipulating the element tree over time is through the animation system. This approach is platform-independent and browser-independent and is the most efficient method.
One caveat: To be animated, the type of the property being animated must have an animation class available in the Silverlight 1.0 animation system. This means that the property that is being animated must be of type Double, Point, or Color. For properties that use other types (for example, integer) you might have to use a timer-called function to simulate animation.
Avoid Animating the Size of Text
Animating the size of text can potentially use a lot of system resources. This is because Silverlight uses hinting to smooth each text glyph when it renders text. If you animate the text size (by using the Transform object or the FontSize property), Silverlight will hint the glyphs for each frame, which is costly and could result in frame-dropping. If your application requires dynamic scale changes of large text, it may be better to use vector graphics to represent the text.
Avoid Using Windowless Mode
Set the Windowless property to true only when necessary. Windowless mode is expensive and can cause tearing during animations.
Use Visibility Instead of Opacity Whenever Possible
If you simply want to make an object discretely visible or not visible, as opposed to using partial opacity or fading the object in or out of view, use the Visibility property instead of Opacity property. Opacity is associated with higher costs because the object is still hit tested and technically rendered. Setting Visibility to Collapsed avoids these costs.
Silverlight Uses Multi-Core in Rendering and Media
Silverlight takes advantage of multi-core for rendering and media playback. Therefore, your Silverlight-based applications will perform faster on multi-core systems.
In Full-Screen Mode, Hide Unused Objects
When your application goes into full-screen mode, hide all objects that are not being rendered in full-screen mode, or disconnect them from the tree. You can hide an object by setting its Visibility property to Collapsed.
Do Not Use Width and Height with MediaElement Objects
Avoid explicitly setting the width and height of a MediaElement object. Instead, let the media element display at its natural size. If you need to change the display size of the element, it is best to re-encode the media to the desired size by using a media encoding tool.
Do Not Use Width and Height with Path Objects
Do not set the Width and Height properties for a Path object. Setting these properties will result in additional stretching, which affects performance. Instead, rely on the explicitly set coordinates of the Path object to control its shape and position, and the Path will have a "natural" width and height.
When Downloader Finishes, Detach Events and Set to Null
When you use the Downloader object, after the Completed event fires, detach all event handlers from the Downloader, and then set Downloader to null. If you reference any content that the Downloader obtained again at a later time, you typically get that content faster because of caching. The performance cost of initializing another Downloader will be more than offset when the Downloader request is able to use cached content, so there is no advantage in keeping the same Downloader instance around to service the same request again later.
Break Up CPU-Intensive Work into Smaller Tasks
When JavaScript is running, the plug-in will stop drawing. Typically, this is not an issue if minimal work is done in the event handlers. However, if your application requires substantial, CPU-intensive work on the JavaScript thread, we recommend that you split that work into smaller tasks. This will allow rendering to keep up with the desired frame rate.