Measuring Drawing Performance
Eliminating unnecessary drawing can dramatically improve the performance of any application. Drawing calls require a lot of overhead, both in setting up the drawing environment and in rendering the final image. The Xcode Tools CD comes with tools for analyzing the performance of your application’s drawing code. You can use these tools to identify areas that are being redrawn unnecessarily.
Using Quartz Debug
Quartz Debug is a Cocoa application that lets you view screen updates as they happen. The application is located in the
/Developer/Applications/Performance Tools directory. Upon launching Quartz Debug, you are presented with the options window, shown in Figure 1. This window contains several debugging checkboxes (all initially deselected) and a Show Window List button.
Viewing Window Updates
The “Autoflush drawing” checkbox causes the window server to flush the contents of a Core Graphics graphics context after each drawing operation.
When “Flash screen updates” is selected, regions of the screen that are about to be updated are painted yellow, followed by a brief pause, followed by the actual screen update. Similarly, areas that are about to be updated via hardware acceleration are painted green. This allows you to see screen updates as they occur. The pause allows you to see the colored region before it disappears; without it, the screen would be updated immediately, possibly faster than you can perceive it. To turn off the pause, enable the “No delay after flash” check box.
When “Flash identical updates” is selected, regions of the screen that were modified, but whose pixels did not change, are painted red, followed by a brief pause, followed by the update. To turn off the pause, enable the “No delay after flash” check box.
By watching the rectangles that Quartz Debug displays, you can determine how often and where your application redraws itself. If you see a large area being refreshed but know the application needs to update only a small portion of that area, you should go back and check your update rectangles. Similarly, if you see any red rectangles, your application is drawing content that has not changed and does not need to be redrawn.
Viewing the Window List
Choose Tools > Show Window List to display a static snapshot of the system-wide window list. The list identifies the owner of each window and the memory the window occupies. This is useful for understanding the impact of buffered windows on your application’s memory footprint.
Table 1 explains the meaning of each column in the window list.
Viewing Additional Information
The Quartz Debug Tools menu includes additional options for testing the performance of your application. From this menu you can view a frame meter that displays the current rendering speed of the system, along with the impact on CPU usage. You can also display a control window for getting and setting the current screen resolution. You can use this latter window to test your resolution-independent rendering code.
Debugging Cocoa Graphics
You can take advantage of several AppKit debugging options to gather data about their application’s drawing performance. These options are in the form of command-line parameters that you pass to your application at launch time. You must launch your application from Terminal to use these parameters.
Table 2 lists the parameters you can use when launching your application.
For example, to display drawing updates, for the TextEdit application using the color blue, and pausing for 500 milliseconds between updates, you would specify the following commands from Terminal:
% cd /Applications/TextEdit.app/Contents/MacOS
% ./TextEdit -NSShowAllDrawing 500 -NSShowAllDrawingColor blueColor