09. The Rendering Landscape

Modules 01–03 taught you to draw charts on Canvas. Modules 05–08 taught you to describe charts with Chart.js (which renders to Canvas internally). The next three modules will use D3.js, which renders to SVG. But why does D3 use SVG? Why does Chart.js use Canvas? When should you use CSS, WebGL, or a static image instead? This module answers those questions by examining the five rendering surfaces available in the browser and the architectural dimensions that determine which one to choose.

1. The Five Rendering Surfaces

Every chart in a web browser is ultimately drawn using one of five rendering technologies. Each has a different rendering model that determines its performance characteristics, interactivity story, and accessibility profile:

The critical distinction is between immediate mode and retained mode rendering. This single concept explains most of the performance and interactivity trade-offs you will encounter.

2. Immediate vs. Retained Mode

These two rendering models are the architectural foundation of every rendering technology in the browser:

Why this matters: At 100 elements, the overhead of retained mode is negligible. At 5,000 elements, reflow and style recalculation become measurable. At 50,000 elements, the page freezes — not because rendering is slow, but because DOM bookkeeping is expensive. Every element participates in the CSS cascade, layout, and event dispatch system.

Open the stress test demo and drag the slider from 100 to 50,000 points. Watch the FPS counters: Canvas stays smooth while SVG degrades.

3. Performance Envelopes

Each rendering surface has a comfortable operating range measured in data points or visual elements. Outside that range, performance degrades — sometimes gradually, sometimes catastrophically:

These ranges are approximate and depend on hardware, but the relative order is consistent. The key insight is that there is no single "best" technology — each has a sweet spot determined by its rendering model.

4. SVG Strengths

D3.js defaults to SVG for good reasons. Within its performance envelope, SVG offers advantages that no other rendering surface can match:

• Resolution independence: SVG scales to any display density without the devicePixelRatio dance that Canvas requires
• CSS styling: Every SVG element can be styled with CSS selectors, including :hover, :focus, and media queries
• Native DOM events: Each <rect>, <circle>, or <path> receives click, mouseenter, and focus events individually
• Accessibility: Screen readers can traverse SVG elements. You can add <title>, <desc>, and ARIA attributes to make charts navigable
• DevTools inspectable: You can inspect, modify, and debug SVG elements in the browser's Elements panel just like HTML
• Real text: SVG <text> elements are selectable and searchable, unlike Canvas text which is painted pixels

Try the hit-testing demo to see SVG's native event handling in action compared to Canvas's manual approach.

5. The DOM Explosion Problem

SVG's strengths come from the DOM. But the DOM is also its weakness. Every SVG element is a full-fledged DOM node that participates in:

• CSS cascade: The browser evaluates style rules against every node
• Layout: The browser computes the position and bounding box of every node
• Event dispatch: The browser maintains event listener registrations for every node
• Memory: Each node consumes ~500 bytes of heap memory (element + attributes + style)

Render 10,000 <circle> elements and you have 10,000 DOM nodes. That is roughly 5 MB of memory just for the DOM objects, plus the ongoing cost of style recalculation on every frame. The rendering itself is fast — painting circles is cheap. The bottleneck is the DOM bookkeeping that happens before painting.

6. Canvas Strengths and Weaknesses

Canvas uses immediate-mode rendering: you issue draw commands and the result is a flat bitmap. Once drawn, shapes have no identity — they are just pixels.

Strengths:

• Fixed memory: A 600×400 canvas always uses the same amount of memory regardless of how many shapes you draw on it
• Fast redraw: Clearing and redrawing 10,000 shapes is faster than updating 10,000 DOM nodes
• Pixel-level control: You can manipulate individual pixels via getImageData() / putImageData()
• Export: canvas.toDataURL() gives you a PNG immediately — no screenshot needed

Weaknesses:

• No native interactivity: To detect which shape the user clicked, you must implement hit-testing yourself (distance calculations, spatial indexing, or a hidden color-picking canvas)
• Invisible to screen readers: The canvas bitmap is opaque to assistive technology. You must provide alternative text or ARIA descriptions manually
• HiDPI handling required: You must multiply canvas dimensions by devicePixelRatio and scale the context to avoid blurry output on Retina displays
• No CSS styling: You cannot use CSS to style canvas-drawn shapes — all visual properties must be set in JavaScript

7. WebGL and WebGPU

When data volumes exceed 100,000 points, even Canvas struggles with per-frame draw loops. WebGL (and its successor WebGPU) solve this by offloading rendering to the GPU, which can process millions of vertices in parallel.

WebGL is used by mapping libraries (Mapbox GL, deck.gl), scientific visualization tools (regl, three.js), and large-scale charting libraries (Plotly with scattergl). WebGPU, the modern successor, provides even lower-level GPU access with better performance and a cleaner API.

8. CSS Charting

CSS can render simple charts without any JavaScript at all. Bars are <div> elements whose width or height is set via calc() or custom properties. This approach has unique advantages:

• Works without JavaScript: The chart renders even if JS is blocked, fails to load, or has not executed yet
• Works in email: Inline CSS charts survive email client rendering where Canvas and SVG do not
• Fully semantic: The underlying HTML can use <dl>, <table>, or ARIA attributes for complete accessibility
• Progressive enhancement: Start with a CSS-only chart, then layer on JavaScript for tooltips and animation

<!-- CSS-only bar chart using custom properties -->
<div class="chart">
  <div class="bar" style="--value: 83">
    <span class="label">/home</span>
    <span class="value">1,250</span>
  </div>
  <div class="bar" style="--value: 29">
    <span class="label">/about</span>
    <span class="value">430</span>
  </div>
</div>

<style>
.bar {
  height: 28px;
  width: calc(var(--value) * 1%);
  background: #16a085;
  margin: 4px 0;
  transition: width 0.5s;
}
</style>

The limitation is that CSS charts are restricted to simple forms — horizontal bars, sparklines, basic progress indicators. Anything requiring axes, gridlines, or complex geometry needs Canvas or SVG. See the CSS bar chart demo for a complete example with progressive JavaScript enhancement.

9. Decision Framework

Choosing a rendering technology is not a single-variable decision. It depends on at least six dimensions. This table maps each dimension to the technologies it favors:

10. Authoritative Comparison

Here is the full comparison across the dimensions that matter for charting:

11. Exercises

1. Stress test observation: Open svg-vs-canvas-stress.html. At what point count does the SVG panel drop below 30 FPS on your machine? How about 10 FPS? Does the Canvas panel ever drop below 30 FPS? Record the numbers.
2. CSS chart extension: Open css-bar-chart.html. Disable JavaScript in your browser's DevTools. Verify the chart still renders. Then add a sixth bar to the HTML and adjust the --value accordingly.
3. Hit-testing analysis: Open hit-testing.html. Read the code panel for the Canvas side. How many distance calculations does it perform per mouse move? What is the Big-O complexity? How could you reduce it?
4. Decision matrix: For each scenario below, identify the best rendering technology and justify your choice:
   • A weekly email report with 5 bar charts
   • A real-time stock ticker showing 500 price points, updating every 100ms
   • An interactive map of 2 million GPS coordinates
   • A dashboard with 6 charts, each showing ~200 aggregated data points

12. Summary

• The browser provides five rendering surfaces: static images, CSS, Canvas 2D, SVG, and WebGL/WebGPU
• Immediate mode (Canvas, WebGL) draws pixels and forgets; memory is constant. Retained mode (SVG, CSS) creates DOM nodes; memory grows with element count
• SVG excels at interactive, accessible charts with fewer than ~5,000 elements. Canvas excels at high-volume rendering up to ~100,000 points
• The DOM explosion problem limits SVG: each element adds overhead for CSS cascade, layout, and event dispatch
• CSS charts require no JavaScript and work in email — ideal for simple, accessible, progressive-enhancement scenarios
• WebGL handles millions of points by leveraging GPU parallelism, but has a steep learning curve
• The right choice depends on six dimensions: purpose, interaction degree, data volume, update rate, accessibility needs, and distribution channel