Overdraw

Overdraw is repeated processing of the same image location during rendering, for example when several overlapping surfaces generate fragments for one output pixel. It can involve shading fragments that are later overwritten or combining several transparent layers. Overlapping transparent interfaces, particles and sprites are common sources of overdraw.

Overdraw is a performance concern in virtual reality (VR) and augmented reality (AR) applications. Microsoft's mixed reality guidance identifies limiting overdraw as a GPU optimization, alongside reducing shader work and diagnosing bandwidth and pixel-processing bottlenecks. Overdraw describes rendering work; the resulting image can still have correct visibility.

Meaning and measurement

In a raster graphics pipeline, rasterization produces fragments representing coverage of image samples. A fragment can be discarded by a depth or stencil test, shaded, or passed onward to framebuffer operations. A generated fragment, a fragment-shader invocation and a final pixel write are therefore different events. Multisampling, sample shading and helper invocations further complicate a one-to-one correspondence between fragments and pixels.

An overdraw measurement must identify which events it counts. Sander, Nehab and Barczak's 2007 research defines an overdraw ratio as the number of pixels passing the depth test divided by the number of visible pixels; a ratio of one represents no overdraw under that definition. Arm's Mali profiling documentation instead describes an overdraw chart as the average number of fragments shaded per output pixel. These definitions address related workloads but use different counting rules.

Related quantity	Relationship to overdraw
Draw call count	Counts commands to draw geometry. Reducing command submission can reduce CPU rendering cost, while overlapping geometry can still require repeated pixel work.
Polygon or vertex count	Describes geometry workload. Screen coverage and fragment cost are separate factors: even a low-polygon skybox can be limited by fragment shading or framebuffer access.
Occlusion	Describes one surface hiding another from a viewpoint. Overdraw concerns how much processing occurs while producing that visibility, including shaded surfaces subsequently covered by nearer ones.
Occlusion culling	Prevents hidden objects from being submitted for rendering. It can remove work before the GPU processes their geometry or fragments.

Depth testing and rendering order

Opaque surfaces

A depth buffer records depth at image samples. With depth testing and depth writes enabled, a passing fragment can replace the stored depth, while a failing sample loses its coverage. This determines visibility, but the amount of shading avoided depends on when the test occurs. Early depth testing, often called early-Z, can reject hidden fragments before their pixel shader executes. Rendering opaque geometry approximately from front to back can establish nearby depth values before farther surfaces reach the expensive shading stage.

For example, if a distant opaque surface is shaded before a nearer surface covers it, its color contribution is overwritten. Drawing the nearer surface first gives an eligible early depth test an opportunity to reject the farther fragment. Depth testing performed after shading can still produce the correct image, but the rejected fragment has already incurred shader work. In Unity's Built-in Render Pipeline, opaque render queues use front-to-back sorting by default. That is an engine policy rather than a rule applying to every renderer or GPU.

Transparent surfaces and cutouts

Conventional alpha compositing combines a foreground color with the background that remains visible through it. The result depends on surface order, so multiple layers are commonly blended from back to front. Glass approximations, smoke and hair can require contributions from several surfaces at the same location. Processing those layers can be necessary to obtain the intended image.

Unity's Built-in transparent queue is intended for alpha-blended shaders that do not write depth. Depth testing against opaque surfaces can still hide transparent fragments behind those surfaces; disabling depth writes does not mean disabling depth tests. Transparent layers that remain visible cannot all be treated as a single opaque occluder without changing the compositing result.

Shader discard and shader-generated depth can affect the GPU's ability to determine visibility early. The consequences depend on the architecture and shader: Arm's fragment pre-pass documentation, for example, explains that late-Z draws may require part of a fragment shader to run during both its visibility pre-pass and main pass.

Processing cost

Overdraw increases the number of times a location can incur fragment shading, texture access or framebuffer operations. The term fill rate is sometimes used broadly for both fragment-shader throughput and framebuffer bandwidth, although these are distinct parts of the pipeline. Alpha blending that uses the destination color requires access to that color as well as an updated result.

The number of layers alone does not describe their cost. A layer with a complex shader can cost more than one using simpler shading. Unreal Engine's Shader Complexity view visualizes shader instruction counts, but Epic warns that instruction count does not capture differences between texture operations and arithmetic, and can misrepresent some loops. A complexity heatmap is consequently an indicator to investigate, rather than a direct timing measurement.

GPU visibility optimizations can also change the relationship between overlapping surfaces and executed work. Arm describes a hardware fragment pre-pass in Immortalis-G925, Mali-G725 and Mali-G625 that identifies visible fragments before the main rendering pass. Its compatible draws do not depend on front-to-back depth order for culling efficiency, but incompatible draws and shader behavior impose limitations. This is a documented architecture-specific example, not a guarantee about other GPUs or drivers.

Relevance to XR rendering

Stereoscopic rendering produces views for the two eyes, so pixel work must be considered across the views actually rendered. Unity distinguishes multipass rendering from single-pass instanced rendering and multiview. Single-pass instancing reduces CPU usage and can reduce GPU usage, but both eye images still have to be produced. Microsoft's holographic rendering documentation also warns that view, resolution and frame-rate parameters can vary across frames and between eyes. A fixed assumption about the pixel workload can therefore be misleading.

The reason to reduce unnecessary work is to help meet the application's rendering deadlines. Microsoft's guidance relates insufficient performance to unstable holograms and inaccurate apparent head tracking, and its rendering overview connects a shorter pipeline with improved hologram stability. An overdraw reduction helps those goals only when the affected GPU work contributes to the application's bottleneck.

Untethered XR adds platform-specific considerations. Unity's URP guidance describes tile-based GPUs as common on these devices and explains that post-processing can introduce additional texture loads, copies and work per view. It advises disabling URP depth priming for untethered XR, where the added depth pre-pass can duplicate work already addressed by hardware visibility mechanisms. That advice is scoped to this rendering configuration.

Foveated rendering is a separate way to reduce pixel workload. Unity's OpenXR implementation uses variable-rate techniques to reduce peripheral rendering resolution, with a fixed or gaze-dependent high-resolution region. It changes sampling density rather than removing the overlapping surfaces that cause overdraw.

Profiling

Profiling first separates CPU limitations from GPU limitations. Lowering render-target resolution and observing a performance improvement is evidence of a pixel-related GPU limitation, but does not by itself identify overdraw as the cause. Shader cost, framebuffer traffic and other resolution-dependent work need to be examined as well.

Tool or view	What it shows	Interpretation
Unity URP Rendering Debugger	An Overdraw debug view showing where Unity draws pixels over one another.	Useful for locating overlap in the render pipeline being inspected.
RenderDoc Texture Viewer	Quad Overdraw overlays for a selected draw or for its pass up to that draw.	Measures overdraw at 2 by 2 quad granularity. The draw and pass scopes are different; neither should silently be treated as a whole-frame pixel count.
Unreal Engine Shader Complexity	A visualization based on shader instructions used per pixel.	Helps identify costly materials and particle effects, with the instruction-count limitations described above.
Arm Streamline Mali counters	Shaded fragments per output pixel, early and late depth/stencil activity, and memory traffic.	Can relate overlap to executed work on the supported GPU. Counter definitions and architecture matter.

Measurements should preserve the distinction between a particular draw, a rendering pass and a frame. RenderDoc also provides a Depth Test overlay to locate areas passing or failing the selected draw's test; this answers a visibility question different from the Quad Overdraw overlay.

Reducing the workload

Different changes address different sources of repeated work. Removing or simplifying overlapping transparent UI, particles and sprites addresses common sources identified in Unity's performance guidance. Simplifying fragment shaders reduces the cost of each remaining layer, while reducing render-target resolution reduces the number of image locations processed. Culling hidden objects before submission can remove geometry work as well as potential overdraw.

A depth-only pre-pass can establish visibility before expensive shading. It also adds a pass over geometry, so its costs must be weighed against the shading saved. Arm distinguishes an application pre-pass that submits and tiles geometry twice from its hardware fragment pre-pass, which keeps intermediate structures on chip. Unity's untethered XR guidance supplies a concrete case where enabling the application technique is discouraged.

Mesh ordering is another approach. Sander, Nehab and Barczak developed algorithms that cluster and reorder triangles to reduce overdraw while retaining vertex-cache locality. Their experiments examine the trade-off between ordering overhead, vertex processing and pixel shading; their measured results concern the tested models, shaders and hardware, rather than a universal XR optimization budget.

Transparent rendering requires preserving the intended composition. McGuire and Bavoil's weighted blended order-independent transparency combines contributions without sorting individual surfaces, using bounded storage and an approximate color-compositing method. It still processes transparent contributions and has image-quality limitations, so removing sorting does not imply removing transparent overdraw.

Reviewed 12 October 2026. Raster overdraw definitions and counting rules, depth and transparency behavior, cited profiling methods, and documented XR rendering implications. Device benchmarks and universal performance budgets were not checked. About review dates.