Optimizing Stroke Rendering with Viewport Culling

The Problem: The Cost of Off-Screen Drawing

Your current render loop, like any naive implementation, likely iterates through every single stroke in your document. While Skia is highly optimized and will clip drawing operations that fall outside the viewport, it doesn't do so for free. For every off-screen stroke, your CPU still spends time iterating, performing checks, and dispatching a draw call to the GPU, even if that call results in zero pixels being drawn.

As you're keenly aware from your interest in high-performance systems, this leads to an unacceptable performance characteristic: the cost to render a frame scales linearly, $O(N)$, with the total number of strokes $N$. When a user is zoomed into a small section of a document containing thousands of strokes, the application should not be wasting cycles processing the vast majority of strokes that are off-screen.

The following article from Grida's engineering blog explains this exact problem. Even though they use an R-tree, the principle is identical for our Quadtree.

The key takeaway is that we must avoid telling the renderer about off-screen objects in the first place.

The Solution: Query, Then Draw

The optimized render loop fundamentally changes the flow of data. Instead of pushing all strokes to the renderer and letting it discard them, we first ask the Quadtree for a minimal set of potentially visible strokes and then provide only that set to the renderer.

The new process for each frame is as follows:

1. Get Viewport: Determine the world-space rectangle that corresponds to the user's current view (the camera's viewport).
2. Query Quadtree: Pass this viewport rectangle to the Quadtree::query() method you built in the previous lesson. This returns a small list containing only the strokes that intersect the viewport.
3. Draw Visible Set: Iterate over this much smaller list of visible strokes and issue draw commands to Skia.

The time complexity of this approach is approximately $O(\log N+k)$, where $N$ is the total number of strokes and $k$ is the number of visible strokes. For a typical zoomed-in view where $k\ll N$, this is a dramatic improvement over the naive $O(N)$ approach.

Modifying the Render Loop

Let's look at how this logic is integrated. This change happens at the highest level of your rendering code, where you orchestrate the drawing for each frame.

The Handmade Hero series provides an excellent, low-level walkthrough of this exact process. Casey Muratori discusses how to use a spatial partition to decide which entities to bring into the "high-frequency" set for processing and rendering—this is precisely what we are doing with our strokes.

Inspired by this, let's sketch out what our modified render function would look like. Assume you have a DocumentLayer class that holds all the strokes and the Quadtree, and a Camera class that can provide its current view bounds.

// In your main rendering class

void Application::onPaint(SkCanvas* canvas) {
    // Clear the canvas for the new frame
    canvas->clear(SK_ColorWHITE);

    // Save the current canvas state
    canvas->save();

    // Apply the camera's transformation (pan/zoom)
    canvas->setMatrix(m_camera.getTransformMatrix());

    // --- The Optimization ---

    // 1. Get the camera's visible bounds in world coordinates
    SkRect viewBounds = m_camera.getViewBounds();

    // 2. Query the document layer for visible strokes using the Quadtree
    std::vector<StrokeIterator> visibleStrokes = m_documentLayer.queryVisibleStrokes(viewBounds);

    // 3. Draw ONLY the visible strokes
    for (const auto& strokeIter : visibleStrokes) {
        // Dereference the iterator to get the stroke object
        const Stroke& stroke = *strokeIter;
        
        // Use your existing function to draw a single stroke
        drawStroke(canvas, stroke);
    }
    
    // Restore the canvas state
    canvas->restore();

    // (Optional) Draw UI overlays, debug info, etc. in screen space
    drawDebugInfo(canvas, m_documentLayer.getTotalStrokeCount(), visibleStrokes.size());
}

Notice how the for loop no longer iterates over m_documentLayer.getAllStrokes(). Instead, it iterates over the visibleStrokes returned by our highly efficient query.

The LearnOpenGL article on frustum culling provides another simple, clear example of this pattern in a render loop.

The Performance Payoff

By implementing this change, you have fundamentally altered the performance characteristics of your application. The Grida article quantifies this impact beautifully.

This is not a micro-optimization; it is a foundational architectural change necessary for any high-performance graphics application dealing with large datasets. It ensures that your application remains responsive and fluid, regardless of how complex the user's document becomes.

As a final point, consider an easy-to-implement edge case: what if the user is zoomed all the way out and the entire document is visible? In this scenario, running the Quadtree query is unnecessary work. A simple optimization is to first check if the camera's viewport fully contains the bounding box of the entire document. If it does, you can bypass the query and revert to the simple loop that draws every stroke. This is an O(1) check that saves you an O(log N) query in a common scenario.

Conclusion

In this lesson, you've connected all the pieces of your spatial indexing system. By modifying the main render loop to first query the Quadtree for visible strokes, you have successfully implemented view frustum culling. This ensures that your application's rendering performance scales with the number of visible objects, not the total number of objects in the scene.

Key Takeaways:

• Optimized Render Loop: The performant approach is to first query for a set of visible objects, then iterate and draw only that small set.
• CPU Overhead: Bypassing draw calls for off-screen objects saves significant CPU time that would otherwise be spent on iteration and function dispatch.
• Scalability: Your renderer's performance is no longer linearly tied to the total document complexity, enabling it to handle massive scenes while maintaining interactivity.
• Architectural Shift: View frustum culling is a fundamental change from a "draw everything" model to a "draw only what's necessary" model, crucial for performance-oriented systems.

You have now completed the core implementation of spatial indexing for culling. The next module, Advanced Rendering Optimizations, will build on this foundation. We will explore techniques like using "dirty rectangles" to avoid redrawing unchanged parts of the screen and implementing a command-based renderer to enable further GPU-side optimizations like batching.