editor-concepts

Canvas vs Legacy Renderer

Lega's editor can draw your design through a fast Canvas2D renderer or a legacy SVG-based fallback. Here's what the difference means for you, and when it matters.

You generally shouldn't need to think about how Lega draws pixels to your screen — that's the point of a good renderer, it disappears. But the fact that Lega has two rendering backends, and that they're guaranteed to produce identical output, is worth understanding, because it explains some behavior you might otherwise find confusing (like why an edit always looks the same after export as it did while you were making it).

One compiled scene, two ways to draw it

Every frame you build in Lega gets compiled into a single internal scene representation — a structured description of every layer, its position, styling, and stacking order. That compiled scene is the source of truth. What differs between the two modes is only how that scene gets turned into pixels on screen:

  • Canvas renderer (the default): draws the scene using the Canvas2D API. This is the faster, more modern path, and it's what almost everyone uses day to day.
  • Legacy renderer: draws the same compiled scene using SVG instead. This exists as a fallback for compatibility — certain environments or edge cases where Canvas2D rendering behaves unexpectedly.

The important guarantee is that both backends render from the exact same compiled scene. There's no separate interpretation step where one renderer might round a position differently or handle a gradient differently than the other. If you switch modes, what you see should not meaningfully change — the whole design of having two renderers was to eliminate drift between them, not to offer two different looks.

Why export always matches what you see

This shared-scene design has a direct, practical benefit: export and thumbnail generation in Lega always render through the canvas backend, using the same draw calls as the live canvas view. That means there's no separate "export renderer" with its own quirks that could produce a result different from what you were looking at while editing. What you see on screen while you work is what you get when you export — see Exporting Your Design for the format and resolution details of that export path.

Tools that maintain separate preview and export pipelines are prone to a specific, frustrating class of bug: the exported file looks subtly different from the editor. Lega's single-scene, dual-backend architecture is built specifically to make that class of bug structurally impossible rather than something to catch in testing.

When the renderer mode actually matters to you

For the overwhelming majority of work, you'll never need to think about which renderer is active — the canvas renderer is the default, it's fast, and it's what the product is built around. The legacy SVG renderer exists as a safety net, not a feature you're expected to reach for.

It becomes relevant in a narrower set of cases: if you're on an environment where Canvas2D rendering is behaving unexpectedly (rendering artifacts, unusual performance characteristics on older hardware, or specific browser quirks), the legacy renderer is the fallback path that trades some performance for broader compatibility. If you ever run into rendering behavior that looks wrong, that's the first thing worth checking or reporting.

The bigger picture

The dual-renderer design is one expression of a broader architectural choice in Lega's editor: keep a single, well-defined source of truth (the compiled scene) and let multiple consumers — the live view, thumbnails, exports, and alternate render backends — read from it consistently, instead of each maintaining its own version of "what the design looks like." That same philosophy shows up elsewhere in the editor's design, covered at a higher level in the Legon Editor Overview.

If you're interested in the engineering story behind why Lega ended up with two renderers sharing one scene compiler — including the specific problems that pattern was built to solve — see Building a Dual-Renderer Canvas: Lessons Learned, which goes into the technical reasoning in more depth than is useful here.