PAINT GPU
OPTIMIZATION

Solutions

Each fix below shows the before code with the problem highlighted, the reason it causes the issue, then the corrected version and why it works.

Fix 1: Batch DrawRenderer and Blit in a single CommandBuffer

The dominant fix. The original Paint() emitted two separate GPU submissions per stamp: one to draw the brush onto the paint texture, then a standalone copy to propagate the result. With up to 100 stamps per frame, this produced 200 dependent submissions the driver had to serialize.

internal void Paint(Paintable p, Vector3 pos, ...)
{
    RenderTexture mask    = p.MaskRenderTexture;
    RenderTexture support = p.SupportRenderTexture;

    MaterialInstance.SetTexture(TEXTURE_ID, support);
    MaterialInstance.SetVector(POSITION_ID, pos);
    // ... other SetXxx ...

    CommandBuffer.SetRenderTarget(mask);
    CommandBuffer.DrawRenderer(p.Renderer, MaterialInstance, 0);
    Graphics.ExecuteCommandBuffer(CommandBuffer); // 1st GPU submission
    CommandBuffer.Clear();

    Graphics.Blit(mask, support); // 2nd GPU submission, separate command list
}

internal void Paint(Paintable p, Vector3 pos,
                    Color color, float radius, float hardness)
{
    RenderTexture mask    = p.MaskRenderTexture;
    RenderTexture support = p.SupportRenderTexture;
    Renderer renderer     = p.Renderer;

    MaterialInstance.SetTexture(TEXTURE_ID, support);
    MaterialInstance.SetVector(POSITION_ID, pos);
    MaterialInstance.SetFloat(RADIUS_ID, radius);
    MaterialInstance.SetFloat(HARDNESS_ID, hardness);
    MaterialInstance.SetFloat(STRENGTH_ID, ConstantsPaint.TRANSPARENCY);
    MaterialInstance.SetColor(PAINTER_COLOR_ID, color);

    CommandBuffer.SetRenderTarget(mask);
    CommandBuffer.DrawRenderer(renderer, MaterialInstance, 0);
    CommandBuffer.Blit(mask, support); // recorded into the same command list

    Graphics.ExecuteCommandBuffer(CommandBuffer); // single submission per stamp
    CommandBuffer.Clear();
}

Fix 2: ITERATION_PER_FRAME 100 → 30

The brush system interpolates between two consecutive cursor positions to draw a continuous stroke. The interpolation step is fixed (0.1 world units), so a fast mouse motion can produce dozens of stamps in a single frame.

The original code yielded back to Unity every 100 stamps, which capped the per-frame budget but was too lenient: the user was generating up to 100 stamps per frame during normal painting, hitting the cap on every frame. Lowering the cap to 30 stamps before yielding spreads the work across several frames at the cost of at most one extra frame of latency, invisible to the user.

public const int ITERATION_PER_FRAME = 100;

public const int ITERATION_PER_FRAME = 30;

Fix 3: Float-precision guard

The interpolation routine builds a list of stamp positions along a line segment between two cursor samples. When the cursor barely moves, the distance between the two samples can be extremely small due to floating-point noise. The original code had no check for this: it would still run the loop and submit stamps for what is effectively a zero-length segment, paying the full GPU cost for an invisible result.

private IEnumerator PaintBetweenPoints(
    Paintable p, Vector3 from, Vector3 to, ...)
{
    Vector3 dir = to - from;
    float length = dir.magnitude;
    dir = dir.normalized; // dangerous if length is near 0 (NaN direction)

    // No minimum-distance check: runs even when from == to
    for (float i = 0; i < length; i += m_stampSpacing)
    {
        m_paintManager.Paint(p, from + dir * i, ...);
        // ... yield every N ...
    }
    m_paintManager.Paint(p, to, ...);
}

private IEnumerator PaintBetweenPoints(
    Paintable p, Vector3 from, Vector3 to, ...)
{
    Vector3 dir = to - from;
    float length = dir.magnitude;

    if (length < 0.001f)
        yield break; // skip if positions are essentially identical

    dir = dir.normalized;
    for (float i = 0; i < length; i += m_stampSpacing)
    {
        m_paintManager.Paint(p, from + dir * i, ...);
        // ... yield every N ...
    }
    m_paintManager.Paint(p, to, ...);
}

Results

Numbers below were captured on the same scene, same input pattern (continuous brush stroke for 5 seconds), same hardware, in standalone build.

CPU and GPU sync

Profiler captures · after

Profiler hierarchy · after

After

Profiler timeline · after

After

Final build · 133 fps stable

After

Conclusion

The whole investigation is a clean illustration of a principle worth restating: on modern GPUs, the cost of a render operation is rarely what you write, it's how the driver sees it. The shader was fine, the texture was fine, the algorithm was fine. The submission pattern was not, and that single dimension of the system explained 14 ms of lost frame time.

What I'd do the same way again

• Read the profiler before touching the code. The WaitOnSwapChain signature pointed at the family of root causes within the first minute. Anything I'd done before reading it would have been guessing.
• Reject hypotheses, even tempting ones. Format downgrade looked free. It wasn't worth it. Profiling each candidate fix in isolation kept the final patch surgical.

What I'd do differently

• Add a profiler marker around the paint call from day one. There was no named scope on the brush path. A 30-second addition would have shortened the diagnosis by half.
• Fold standalone copy operations into the surrounding command list. Graphics.Blit is convenient but always flushes a new command list immediately. On any per-frame loop where a CommandBuffer is already open, that copy belongs inside the same buffer, not after it.

Takeaways

1. WaitOnSwapChain above 5 ms: look at submit count, not at shader cost.
2. Two GPU operations that read each other's output should always live in the same CommandBuffer.
3. Float-precision guards on input-driven code paths cost nothing and remove a class of bugs.
4. Format optimization is a last resort, not a first instinct.

Project: Timeline · Gambas Studio Application · Unity 6 · URP · D3D12 · 2026.