- 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
Understanding the Frame Rate Counter
Developing for a mobile device requires particular attention to performance. Mobile devices have less computing power than desktop systems and are more susceptible to performance bottlenecks.
The Windows Phone SDK comes with a built-in control that allows you to monitor the performance of your app, including frames per second and memory usage.
By default, the frame rate counter is enabled in your app’s App.xaml.cs file if a debugger is attached, as shown in the following excerpt:
if(System.Diagnostics.Debugger.IsAttached) {// Display the current frame rate counters.Application.Current.Host.Settings.EnableFrameRateCounter =true; ... }
The EnableFrameRateCounter property is somewhat of a misnomer because the control also reports a number of other UI metrics, such as texture memory usage, as shown in Figure 2.3.
)
FIGURE 2.3. The Frame Rate Counter.
Each field is updated periodically while the app is running. Table 2.1 describes each counter field.
TABLE 2.1. Frame Rate Counter Field Descriptions
|
Field |
Description |
|
Composition (Render) Thread Frame Rate (FPS) |
The rate at which the screen is updated. It also represents how often supported animations driven by a storyboard are updated. This value should be as close to 60 as possible. Application performance begins to degrade when this value is below 30. The text in this counter is red when displaying a value below 30. |
|
User Interface Thread Frame Rate (FPS) |
The rate at which the UI thread is running. The UI thread drives input, per-frame callbacks, and any other drawing not handled by the composition thread. The larger this value, the more responsive your application should be. Typically this value should be above 20 to provide an acceptable response time to user input. The text in this counter is red when displaying a value below 15. |
|
Texture Memory Usage |
The video memory and system memory copies of textures being used in the application. This is not a general memory counter for the application but represents only memory that surfaces use. |
|
Surface Counter |
The number of explicit surfaces being passed to the GPU for processing. The biggest contributor to this number is automatic or developer-cached elements. |
|
Intermediate Surface Counter |
The number of implicit surfaces generated as a result of cached surfaces. These surfaces are created in between UI elements so that the application can accurately maintain the Z-order of elements in the UI. |
|
Screen Fill Rate Counter |
The number of pixels being painted per frame in terms of screens. A value of 1 represents 480×800 pixels. The recommended value is about 2.5. The text in this counter turns red when displaying a value higher than 3. |
Source: MSDN: http://bit.ly/l8i020
The frame rate counter is a valuable tool for identifying performance bottlenecks in your app. For more detailed performance metrics turn to the Application Analysis tool, discussed next.