Measuring Graphics Performance in Your iOS Device
Extensive use of graphics in your app can make your app stand out from your competitor. But unless you use graphics resources responsibly, your app will slow down and look mediocre no matter how good the images you are trying to render.
Use the three trace templates found in the iOS Graphics section to profile your app. Ensure that the frame rate is high enough and that your graphics don’t impede your app’s performance.
Measuring Core Animation Graphics Performance
Instruments uses the Core Animation instrument to measure your app’s graphical performance on iOS devices. The Core Animation trace template provides a quick and lightweight option for measuring the number of frames per second rendered by your app. This instrument is not intended to be used to measure OpenGL ES performance. You can quickly see where your app renders fewer than expected frames. By correlating what you were doing at the time the sample was taken, you can identify areas of your code that need to be improved.
Correlate your interactions with your app with the results displayed in Instruments. In Figure 9-1, you can see spikes where the frame rate of the app becomes appreciably better. Without knowing what was happening with the device during these spikes, it would be natural for you to want to duplicate these higher frame rates throughout the app. However, these spikes were caused by orientation changes when the device was changed between landscape and normal orientation. Without knowing that an orientation change by the device was performed, you might spend time trying to find what caused the performance increase and replicating it throughout your app.
Core Animation contains several useful debugging options in the Detail pane. You do not need to be running a trace in order to see these options working on your iOS device. Select the running process from the Target pop-up menu.
Color Blended Layers. Shows blended view layers. Multiple view layers that are drawn on top of each other with blending enabled are highlighted in red. Reducing the amount of red in your app when this option is selected can dramatically improve your apps performance. Blended view layers are often the cause for slow table scrolling.
Color Hits Green and Misses Red. Marks views in green or red. A view that is able to use a cached rasterization is marked in green.
Color Copied Images. Shows images that are copied by Core Animation in blue.
Color Immediately. When selected, removes the 10 ms delay when performing color-flush operations.
Color Misaligned Images. Places a magenta overlay over images where the source pixels are not aligned to the destination pixels.
Color Offscreen-Rendered Yellow. Places a yellow overlay over content that is rendered offscreen.
Color OpenGL Fast Path Blue. Places a blue overlay over content that is detached from the compositor.
Flash Updated Regions. Colors regions on your iOS device in yellow when that region is updated by the graphics processor.
Measuring OpenGL Activity with the OpenGL ES Analysis Trace Template
The OpenGL ES Analysis template measures and analyzes OpenGL ES activity in order to detect OpenGL ES correctness and performance problems. It also offers you recommendation for addressing found problems. It consists of the OpenGL ES Analyzer and the OpenGL ES Driver instruments.
Open the OpenGL ES Analysis template in the iOS group.
Click the Choose Target pop-up and select your iOS device.
Click the Choose Target pop-up a second time and choose the app you want to analyze.
Click the Record button to begin recording data, and exercise your OpenGL graphics code.
Click the Stop button when issues stop accumulating in the detail pane.
Errors are listed in the Detail pane, showing total occurrences, unique occurrences, category, summary, and (at the far left) a severity code that is either a red square for most severe, or an orange triangle for less severe. When an error is selected a recommendation is provided in the Extended Detail pane on how to fix the detected problem.
Finding Bottlenecks with the OpenGL ES Driver Trace Template
The OpenGL ES Driver trace template is also used to measure app performance and provides you with more information than just the number of frames per second that your app renders. The Extended Detail pane displays all of the gathered information for a specific sample. Each statistic can also be displayed in the track pane by configuring the OpenGL ES Driver to display that particular statistic. For detailed information about the statistic offered, see “OpenGL ES Driver Instrument” in the Instruments User Reference.
Bottlenecks for an OpenGL app often come in two forms, a GPU bottleneck or a CPU bottleneck. GPU bottlenecks occur when the GPU forces the CPU to wait for information as it has to much information to process. CPU bottlenecks often occur when the GPU has to wait for information from the CPU before it can process it. CPU bottlenecks can often be fixed by changing the underlying logic of your app to create a better overall flow of information to the GPU. The following shows a list of bottlenecks and common symptoms that point to the bottleneck:
Geometry limited. See whether Tiler Utilization is high. If it is, then look into your vertex shader processes.
Pixel limited. See whether Rendered Utilization is high. If it is, then look into your fragment shader processes.
CPU limited. See whether Tiler and Rendered Utilization are low. If both of these are low, the performance bottleneck may not be in your OpenGL code and you should look into the your code’s overall logic.