The Enable Debug Control checkbox allows you to enable or disable access to WPF shared memory. By default, Perforator enables this option on startup, and disables this option on termination. In the event of an abnormal termination of Perforator, restart it and manually uncheck the Enable Debug Control checkbox to disable access to WPF shared memory. Then, restart Perforator and the WPF application you were profiling.

Note:
Enabling this option may cause a small increase in memory usage and a small decrease in performance when running WPF applications. You should ensure that Perforator disables this option correctly.

Registry Key Setting

To use Perforator, start the WPF application whose rendering behavior you want to analyze. Once the application has started, click the Refresh button in Perforator. The application should now appear in the Perforator list box of WPF applications. Select the application and the rendering options you want to analyze. The Perforator data values, such as frame rate, immediately reflect the rendering behavior of the application.

Perforator with application and rendering options selected

The following screenshot displays the PhotoDemo sample application with the "Draw software rendering with purple tint" and "Show dirty region support" rendering options enabled:

PhotoDemo sample application displays rendering behavior

The following sections discuss the major performance issues involved in rendering, and how Perforator options and data output can help you diagnose these issues.

Because the WPF hardware rendering pipeline is substantially faster that its software rendering pipeline, the less application UI that renders in software, the faster rendering in that application will be. Typically the time it takes to render an area in software is proportional to the number of pixels rendered, so be wary of large areas rendered using the software pipeline; small areas are of less concern.

Here are the Perforator options that can help detect software rendering issues:

• Draw software rendering with purple tint: Draws all areas rendered using the software rendering pipeline with a purple tint. This includes software render targets, software 3D content, and per-primitive software fallback.

• Num Software Render Targets: Counts the full-window render targets that are running entirely in software. If the count is not 0, this represents a significant performance problem, usually related to machine configuration or the presence of layered windows. Make sure that Microsoft Direct3D is enabled (run dxdiag), ensure that all monitors are set to 32 bits per pixel (BPP) bit depth, and make sure the graphics card is supported by Microsoft DirectX 9.0.

• Num Hardware Render Targets: Counts the full-window render targets that are running in hardware. This number should be equal to the number of windows for the application, times the number of display adapters. This indicates an application is being hardware accelerated wherever possible.

Intermediate Render Targets are additional images that WPF needs to draw in order to get content ready for drawing to the screen.

• Maximum SW/HW IRTs per Frame: Shows the maximum number of software or hardware Intermediate Render Targets being applied to render any one frame of the application. Intermediate Render Targets are usually caused by the use of DrawingBrush, VisualBrush, Opacity on a Visual, or Tile modes on a TileBrush. If this number is very high, it can be an indication that the WPF runtime is performing a large amount of work to render your application.

• Dirty Rect Addition rate: Indicates that fast updates are being triggered in your application.

• Frame rate: Reports the rate at which the application is rendering to the screen. For applications without animation, this value should be near 0, since the dirty region optimizations should avoid drawing except when necessary. Treat this number as an estimate.

• Estimated video memory usage: Tracks large allocations of video memory made directly by WPF (textures and render targets). This does not track allocations made by a given video driver during rendering, allocations caused by the compilation and loading of pixel or vertex shaders, or allocations for vertex or index buffers. Note that exceeding the available amount of texture memory will usually cause WPF render logic to fall to software, and that multiple displays (multi-mon) has a multiplicative effect on the amount of video memory required for an application.

Because Windows Presentation Foundation (WPF) only updates portions of the window as required, it can be helpful to visualize what proportion of the window is being updated at any time. The following options help visualize the update behaviors.

• Show dirty-region update overlay: Causes each update WPF makes to the screen to be indicated by recoloring. This allows you to see what areas are redrawn in a running application, and when.

• Clear Back Buffer Before Rendering: Causes the window to be cleared before each drawing operation.

• Disable Dirty Region Support: Causes WPF to redraw the entire window anytime any change is made, instead of only redrawing the portion of the window that has changed. This can be useful for forcing your entire window to update, but be warned: enabling this will cause your application to render much more slowly.

Perforator allows you to disable certain performance-intensive operations to determine whether they are causing bottlenecks in your application.

• Disable Opacity Effects: Disables certain potentially performance-intensive uses of opacity. To avoid this performance issue in general, consider setting opacity on a low-level object, such as Brush, instead of a high-level object, such as Button.

• Disable per-primitive software fallback: Disables software fallback for individual rendering primitives. Software intermediate render targets and other software rendering cannot be disabled.

• Disable high-quality image rescaling: WPF rescales large images to look better if they are being displayed at a small size. This operation is performance intensive, especially in applications which have many large images being displayed at reduced sizes on screen. This option allows you to disable this rescaling to see if it is the source of a performance problem. To avoid this, consider decoding your images to a size near the size at which they will be displayed.

• Disable 3D rendering: Turns off all 3D drawing operations.

The WPF Visual Profiler presents performance issues in the context of the basic building blocks that are used to construct visual scenes in your application. These building blocks include high-level objects, such as Button and TextBlock controls, as well as low-level objects, such as Line and Ellipse elements. Instead of describing performance issues in terms of call graphs of functions names, Visual Profiler describes these issues using the representation of visual objects. This is similar to the way the Windows SDK tool, UI Spy, represents information. For more information, see UI Spy (UISpy.exe).

In order to analyze the breadth of WPF performance issues, it is necessary to understand the role and scope of underlying WPF services. These services include layout, rendering, and animation. Visual Profiler provides a graphical representation of how WPF services are allocated among application objects. For example, when Visual Profiler displays the visual tree of application objects, it overlays different shades of red on the objects in order to represent the relative amount of resources the object is using. An object that is displayed with a darker red overlay represents an object that uses a higher proportion of resources that an object with a lighter red overlay. More importantly, Visual Profiler provides a breakdown of the amount of specific WPF resources an object consumes.

To use Visual Profiler, click the Start Profiling button and choose Launch or Attach. In order to use the Attach option, both WPFPerf and the application you are profiling must be running with administrative access. Also, the overlay functionality is disabled, and fewer events are available for the Attach option. The Launch option is the recommended option.

The Events tab enables you to choose the application and element events you want to profile.

You can set the Visual Profiler configuration to enable or disable the profiling of the following application events. Those events that are methods are represented by the method name followed by the class name in parentheses. For example, Tick (TimeManager) represents the TimeManager.Tick method.

You can set the Visual Profiler configuration to enable or disable the profiling of the following element events:

When you have finished selecting the application and profiling options, click the OK button to begin profiling the application.

Run your application and the Visual Profiler tool side by side and notice the changing values in the tool. By expanding the visual tree hierarchy, you can select a specific visual object to profile, such as a Grid control. The CPU Usage section of the Visual Profiler gives you a precise breakdown of the use of WPF services by both the object and application. The CPU Utilization data for the element lists:

• Inclusive Time The CPU utilization for the element and all its descendants.

• Exclusive Time The CPU utilization for only the element.

Visual Profiler display output

Visual Profiler overlays different shades of red on the objects in the visual tree in order to represent the relative amount of resources the object is using. An object that is displayed with a darker red overlay represents an object that uses a higher proportion of resources that an object with a lighter red overlay.

The working set of an application is a collection of those pages in its virtual address space that have been recently referenced. It includes both shared and private data. The shared data includes pages that contain all instructions your application executes, including those in your DLLs and the system DLLs. As the working set size increases, memory demand increases. For more information on the working set, see Process Working Set.

Virtual Address Dump (VaDump) creates a listing that contains information about the memory usage of a specified process. This tool is located in the following directory:

~\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\winnt

Important Note:
You must ensure that the system execution path includes the directory location of VaDump. Otherwise, Working Set Analyzer will not function correctly.

To use Working Set Analyzer, start the WPF application you want to profile. After you have started Working Set Analyzer, choose the Select Process option:

Working Set Analyzer Select Process Dialog Box

Select the process whose working set you want to analyze; then, click the Capture button. The Working Set Analyzer first invokes VaDump to generate memory usage information. Next, it parses the information and presents it in a graphically-rich format.

Note:
The working set data represents a static view of memory usage. You may want to generate several sets of working set data at different points in your application, and compare the differences in memory usage.

When the working set data is ready to view, Working Set Analyzer generates a tree view that represents the dynamic data, system data, and application modules.

Working Set Analyzer memory usage categories

For WPF applications, the WPF Modules category contains modules that are system-specific to WPF. Click the category you want to display and a set of pie charts displays. For example, clicking the WPF Modules category displays the following information on the left side of the window.

Working Set Analyzer memory usage pie chart for WPF Modules

The caption at the top displays the total size of the working set category. In this case, WPF Modules represents 9160KB of memory usage. This pie chart represents the individual memory usage of all modules that define the WPF Modules category.

Note:
The size of a memory usage category reflects the memory usage of your application at the moment the working set information was captured.

The small table represents the memory usage of shared, sharable, and private bytes.

Working Set Analyzer memory usage table

The shared bytes category represents the amount of memory that could be potentially shared by other WPF applications.

Viewing Application Memory Usage

To view the memory usage for your application, select the name of the executable file from the Other Modules category in the Working Set tree view.

Working Set Analyzer memory usage categories

To save the current working set usage information, select File from the main menu of Working Set Analyzer. Then, click the Save VADump output button. Once you have saved the working set usage information, you can generate another snapshot of memory usage by clicking the Capture button. To reload a file containing VADump content, select File from the main menu of Working Set Analyzer. Then, click the Open VADump output button.

The Working Set Analyzer provides a time delay feature that allows you to capture working set usage information after a specified interval of time. Select Actions from the main menu of Working Set Analyzer. Then, click the Launch Process… button.

Specify the application you want to run, using the Browse button if needed. Next, enter any arguments for the application. Finally, enter the number of seconds you want to delay the capture of memory usage information. Then, click the Launch button. The status text at the bottom of the Working Set Analyzer counts down the number of remaining seconds until capture, which allows you time to modify your application's state. Once the capture is complete, the status text displays "Done".

The Event Trace main window displays a set of options that allow you to add, save, and view event logging information:

Event Trace main window

Adding a New Event Logger

To add a new event logger, click the Add button from the Event Trace main window. The Add New Logger dialog box displays a set of information for you to define. The Logger Name refers to the user-friendly name of the logger. Select one of the four types of event loggers from the dropdown list box that is labeled GUID:

• NT Kernel Logger

• Common Language Runtime Garbage Collection

• Windows Presentation Foundation - Performance Only

• Windows Presentation Foundation -All

There are two types of WPF event loggers. The "Performance Only" version is a reduced subset of the "All" version. The Log File allows you define the filename for the event log file. Click the button labeled "…" to define the filename. Event log files use the default file extension, "etl".

The Level option refers to the following severity levels that you can use. Higher numbers imply that you get lower levels as well. For example, if you specify 3, you also receive all warning, error, and fatal events:

Level	Description
1	Abnormal exit or termination events.
2	Severe error events.
3	Warning events such as allocation failures.
4	Non-error events such as entry or exit events.
5	Detailed trace events.

The Flags option specifies the class of WPF events. In most cases, the default value is sufficient.

When you have finished creating the new event logging information, click the Add button of the Add New Logger dialog box to add the logger to Event Trace. You can create additional event loggers and add them to Event Trace. When you have finished adding all the event loggers, click the Done button.

Add New Logger dialog box

To remove a specific event logger, select the event logger in list box and click the Remove button. To remove all event loggers, click the Clear button.

Enabling Event Logging

Select the event logger from the list of event loggers in the Event Trace main window. Click the Start button to enable logging. The status for the event logger should display Enabled.

Event Trace main window with an event logger selected

When you have finished logging the events for your application, click the Stop button. To ensure that you have captured event logging information, you may want to view the event log file. Click the Open Log button to view the event log file.

Event Trace main window with event log information

The event log file lists five columns of information for each event.

Column	Description
Time	Current time in CPU ticks.
Guid	GUID corresponding to the event.
Name	Event name.
Event type	Info, Start, or End event. A Start event has a matching End event.
Data	Data related to a specific event type.

The event log information is not very useful in this format. Use the WPF ETW Trace Viewer profiling tool to analyze the output of an event log file created with Event Trace.

You can view an ETW log file that you created and saved using the WPF Event Trace profiling tool. Event log files use the default file extension, "etl". Select File from the main menu of ETW Trace Viewer. Than, click the Open to load the desired log file.

ETW Trace Viewer main window with log file

Once the log file is loaded, ETW Trace Viewer displays a timeline that represents the duration of the event log capture. You can change the unit of measurement for the timeline to be either in seconds or milliseconds. You can choose which types of events you want to view by enabling or disabling specific event types. If you are interested in viewing a small number of event types, you can click the Disable All button to disable all events, and then click the checkboxes for the event you want to enable. The enabled event types for the timeline appear in the bottom right of the ETW Trace Viewer.

You can click and drag the mouse on the time line to view only those events that occurred during the selected area of the timeline. To zoom in on the selected area of the timeline, right click to display the popup menu illustrated in the following screenshot.

ETW Trace Viewer main window with popup menu

The popup menu allows you to zoom in and out of the timeline, as well as show all events and clear the currently selected area of the timeline. When you zoom in on the timeline, the time interval that is displayed in blue indicates the length of the zoomed in timeline. The time interval that is displayed below, in black, indicates the time relative to the overall duration of the event log capture.

ETW Trace Viewer main window with zoomed in data

You can click the small boxes on the timeline to display information about a specific event.

Generating an Event Log File

The PresentationTraceSources class provides debug tracing support for Windows Presentation Foundation (WPF) applications. Tracing is a diagnostics system by which an application's progression can be tracked. The tracing statements report information, much the way the WriteLine method is often used. However, tracing statements can be switched on or off by using a configuration file. In addition, the output of tracing statements can be customized.

For other related .NET Framework diagnostic classes, see System.Diagnostics.