Overdraw in Mobile Apps: What It Is, Causes and Optimization

What is Overdraw in Mobile Graphics?

Overdraw is a situation where the same screen pixel is redrawn multiple times within a single render frame. In an ideal scenario, each pixel should be written exactly once, but in real interfaces due to nested Views, background images and transparent layers, the GPU performs repeated writes.

Each additional redraw increases the frame render time. At a standard 60 FPS rate, each frame gets approximately 16.6 ms. If overdraw causes this limit to be exceeded, the frame rate drops to 30 FPS or lower, which noticeably degrades interface smoothness.

According to Android Performance Patterns by Google, an app with a 3x overdraw factor spends three times more time on the fragment shader than an app with 1x overdraw. On low-performance GPU devices, this leads to noticeable lag during scrolling and animation.

For mobile developers, understanding overdraw is critically important: this factor most often causes jerky scrolling and low frame rates in seemingly simple screens with a large number of nested elements.

How Overdraw Affects GPU Performance

The GPU pipeline consists of several stages: vertex shader, rasterization, and fragment shader. The fragment shader is the most expensive part because it executes for every pixel of every primitive. With 2x overdraw, the fragment shader processes twice as many pixels, which directly increases frame time.

Modern mobile GPUs such as Qualcomm Adreno and Apple GPU have Early-Z Test and Hidden Surface Removal mechanisms that partially compensate for overdraw. However, these optimizations only work under certain conditions, and one should not rely solely on hardware acceleration.

For example, when rendering semi-transparent elements, hardware Early-Z is ineffective, and each pixel is processed fully — overdraw in such scenarios can reach 5x and higher.

Main Causes of Excessive Redrawing

Multi-layered backgrounds are one of the main causes of overdraw in mobile apps. When an Activity or ViewController sets a background color, each nested View can add its own background, and the pixel is redrawn at every hierarchy level.

A study by Uber Engineering showed that removing excessive backgrounds in their Android app reduced overdraw by 32% and screen rendering time by 25%. A similar situation exists in iOS: setting opaque = true for non-transparent Views eliminates alpha blending and prevents multiple pixel writes.

• Transparent overlays — elements with alpha channel on top of other elements always cause overdraw.
• ClipChildren=false — disabling clipping of child elements leads to rendering of invisible areas.
• Using ShapeDrawable instead of simple colors increases the load on the fragment shader.
• Excessive nesting — each View hierarchy level adds a potential redraw layer.

On the iOS platform, overdraw often occurs due to the use of transparent UIStackView, CALayer with shouldRasterize, and overlapping UIBlurEffect. Apple recommends checking overdraw through the Core Animation tool in XCode — it shows redraw zones as a red overlay.

How to Diagnose Overdraw: Tools and Methods

Debug GPU Overdraw is a built-in Android tool that colors the screen differently depending on the overdraw factor. Purple means 1x, blue — 2x, green — 3x, pink — 4x, red — 5x or more. An ideal screen should be mostly purple.

In iOS, similar diagnostics are performed by the Core Animation tool in XCode Instruments. It visualizes redraw zones and shows the exact number of pixel writes in Color Blended Layers mode. Green layers are opaque (optimal), red ones contain transparency and cause overdraw.

• Profile GPU Rendering in Android shows a histogram of render time. Tall green bars indicate overdraw problems.
• Renderscript is a more advanced tool for analyzing the rendering pipeline on Android 10+ devices.
• Metal Debugger in XCode allows you to analyze each render pass and see the exact number of fragment shader calls.

After diagnosis, it is important to measure FPS before and after optimization. A difference of 10–15 FPS when fixing overdraw is a normal result for a complex screen with lists and animation.

Overdraw Optimization Techniques in Mobile Apps

Removing excessive backgrounds is the simplest and most effective method. On Android, just set android:windowBackground only for the Activity or theme, not for each View. On iOS, opaque = true for all non-transparent UIView reduces overdraw to almost zero for those elements.

According to Google I/O 2019, overdraw optimization in Google Maps allowed reducing frame render time by 40% through layer merging and using ClipRect to limit the drawing area. For Android developers, Google recommends the following practices:

• ClipRect — limits the Canvas drawing area. If nothing exists outside the visible area, the GPU does not waste resources.
• ViewStub — for rarely used or initially invisible elements. The component renders only when inflate is called.
• merge and include — reduce the depth of the View hierarchy, which decreases the number of render passes.
• Flat buffers — replacing nested Layouts with a single ConstraintLayout or RelativeLayout.

In iOS, optimization is achieved through CALayer configuration: setting masksToBounds = true clips content beyond the layer bounds, and shouldRasterize enables bitmap caching for static layers.

Code Examples: Eliminating Overdraw in Android and iOS

Let’s look at practical examples in Kotlin and Swift demonstrating typical overdraw elimination scenarios. The first example shows optimization through ClipRect in Android:

class OptimizedView@JvmOverloads constructor(
    context: Context, attrs: AttributeSet? = null
) : View(context, attrs) {

    override fun onDraw(canvas: Canvas) {
        canvas.clipRect(
            paddingLeft.toFloat(), paddingTop.toFloat(),
            width - paddingRight.toFloat(), height - paddingBottom.toFloat()
        )
        // Draw content only within clipped area
        super.onDraw(canvas)
    }
}

The second example in Swift shows disabling transparency for a layer if the element should not be semi-transparent:

class OpaqueLabel: UILabel {
    override var isOpaque: Bool {
        get { true }
        set { }
    }

    override func draw(_ rect: CGRect) {
        backgroundColor?.setFill()
        UIRectFill(rect)
        super.draw(rect)
    }
}

The third example demonstrates using ViewStub for deferred map loading in Android. ViewStub does not render until it becomes visible, which eliminates overdraw at the screen initialization stage:

<!-- layout/activity_main.xml -->
<ViewStub
    android:id="@+id/map_stub"
    android:layout_width="match_parent"
    android:layout_height="200dp"
    android:inflatedId="@+id/map_container"
    android:layout="@layout/map_fragment" />

// Inflate on demand
ViewStub stub = findViewById(R.id.map_stub)
stub?.inflate()