Categories
android ui

Optimizing Layouts in Android – Reducing Overdraw

You have a great idea and you have launched your application into the wild. Now you hear people complaining how your app is slow and horrible to use. Sad face.

One such step to improve the rendering time of your application is to have a look at the GPU Overdraw tool.

What is Overdraw?

Overdraw happens every time the application asks the system to draw something on top of something else. The “Debug GPU Overdraw” tool overlays colours on top of your screen to indicate how many times a pixel has been redrawn.

How do I enable the tool Debug GPU Overdraw?

  1. Go to Settings on your device.
  2. Go to Developer Options
  3. Select “Debug GPU Overdraw”.
  4. Select “Show overdraw areas”

You will notice your screen change colour – don’t panic. Navigate to your application and now we can begin to understand how to improve our layouts.

What do the different colours mean?

Screenshot_2016-02-01-11-08-40The colours mean the following things:

Original colour – no overdraw – The pixels have been painted once on the screen.

Blue – 1x Overdraw –  The pixels have been painted 2 times on the screen.

Green –  2x Overdraw – The pixels on the screen have been painted 3 times on the screen.

Pink – 3x Overdraw – The pixels on the screen have been painted 4 times on the screen.

Red – 4x Overdraw – The pixels on the screen have been painted 5 times on the screen.

GPU Overdraw

You can see from my Book Dash application, that my initial layout was doing a lot of overdraw. 🙁

How do you fix overdraw?

In the example above, I removed the background colour that was set on the RelativeLayout and let the theme draw the background.

So going from this:

<RelativeLayout
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:background="#FFFFFF">

to this:

<RelativeLayout
     android:layout_width="match_parent"
     android:layout_height="match_parent">

Modifying the layout yielded the following result 😊:

After removing the background colour.As you can see, the overdraw has been minimized. The red overdraw has been reduced.

This could be further improved to the layout showing mostly its true colour and a slight amount of blue overdraw. Some overdraw is inevitable.

Not all cases of overdraw are related to background colours. Other problems can be present too, like very complex layout hierarchies or too many views.

You should aim for a maximum overdraw of 2x (Green).

You can also use other tools to see why overdraw is happening, tools such as Hierarchy Viewer and GL Tracer.

How do you debug overdraw issues? Do you have any other tips to share?

Also, you should totally Download the Book Dash App or contribute on Github!

Links:

http://developer.android.com/tools/performance/debug-gpu-overdraw/index.html
Get it on Google Play

12 replies on “Optimizing Layouts in Android – Reducing Overdraw”

What about the case of layout-phases? Which would help to find what causes layout of entire views?
Is it “show surface updates” , or is it “show GPU view updates” ?
I ask this because I’ve found there is a difference between them:
For some reason, having a simple EditText with a focus on it will cause the entire screen flash when “show surface updates” is enabled, yet only the EditText itself when “show GPU view updates” is enabled.
This is weird because I remember an old lecture saying that “show surface updates” is the way to go.

Opened navigation drawer (from support design lib) is a common scenario of overdrawing almost the whole screen. Is there a way to fix that?

Learned a lot! Is it ok that I translate it into Chinese and post it on my own blog? It’s just for sharing this knowledge, no commercial intentions. I will leave a link back to this page at the beginning of the article, of course. Thanks!

There’s an extra note. That won’t work in case hardware acceleration is disabled for you app in the manifest file. By default it’s enabled by the way.

Show surface updates – Makes the edge of a “window” flash when its contents are updated.

Show GPU view updates – Any view that is drawn with the GPU hardware gets a red overlay.

So I guess you whole view is flashing when an update is being made, and the EditText is being drawn with the GPU.

For me, “Show surface updates” is just annoying and doesn’t provide as much value as something like GL Tracer to see exactly what commands are being sent to the GPU. I guess its a quick indicator for you to see that your app is updating the contents often, then using something like GL Tracer to show what exactly is being drawn so many times, frame by frame.

I would assume its the nature of the navigation drawer library because it overlays the content of your application, I would think it has at least drawn the content underneath and then the colour of your navigation drawer. Leaving you with a blue-ish colour, and then the text on top would make it green.

Looking at GMail, the overlay from navigation drawer renders the same colours too.

But what helps for finding what re-invalidates the layout-phases ?
And, why does “show surface updates” flash entire screen when putting an EditText?
I don’t think GPU matters much in what I’ve asked about…
If I have a very complex layout of the activity, and a view causes re-layout of the entire view hierarchy , it means a lot of CPU work will be done for the UI, and this causes things to “jump” for the user.

Actually in GMail when drawer is open its colors goes from blue to red and it looks like nothing is rendered underneath, where in my app with open drawer I can see text spaces which is rendered underneath marked with green or red

Ok, You removed the relativeLayout background in order to reduce overdraw BUT you lost the color between each Book. So how can you keep the background color but removing the part under each book ??

Comments are closed.