You copied the Doc URL to your clipboard.

3.6.2. Areas to investigate

There are a number of areas you can investigate with the technique described in Technique for locating the exact problem areas. You can follow the technique exactly by disabling code and assets. Alternatively you can try using simpler versions.

Change resolution

Change the resolution of your application and measure the frame rate difference.

If the frame rate scales with the inverse of the resolution, that is the performance halves when you double the resolution, your application is pixel processor bound.

Change texture size

Change the size of your textures to 1 by 1. If the frame rate increases, the texture cache hit rate is too low.

Use a stub driver

A stub driver replaces the OpenGL ES driver with a driver that does nothing. The frame rate produced when using a stub driver indicates the CPU usage. If the frame rate does not change from using the normal driver your application is CPU bound.

Reduce shader length

If you shader is too long it can reduce your frame rate. Try shorter shaders and measure the changes.

If the frame rate increases the shader length might be trying to do too much, or is too long.


The number of cycles the Mali pixel processor spends shading is proportionate to the frame size and frame rate. If you double the frame size the number of cycles available halves.

Use an empty fragment shader

An empty or null shader indicates if you are shader bound.

A null shader does no work. Replace your shaders with null shaders and measure performance. If performance rises sharply your application is likely shader bound.

Change number of vertices

A large change when using simpler models indicates your application might be using too many vertices or is bandwidth bound.

Change the bit depth of textures

If application performance rises when you reduce the bit depth of textures, memory bandwidth might be a problem.

Change the bit depth of the drawing surface

If application performance rises with a lowering of texture bit depth memory bandwidth might be a problem.

Reduce draw calls

Using too many draw calls is a common problem. Moving the same amount of work into a smaller number of draw calls might indicate this is a problem area.

Reduce state changes

Reducing the number of state changes might indicate this is a problem area.

Was this page helpful? Yes No