RFC: Live typst preview

[dsturnbull]

Commit: 172fe93 / https://github.com/dsturnbull/zed/tree/typst-preview

Companion tinymist fork: https://github.com/dsturnbull/tinymist (1 commit on top of upstream)

Problem

There's no live preview for typst documents in Zed. The typst extension launches tinymist as a language server, which already does incremental compilation with comemo memoisation on every keystroke, but there's no way to see the rendered output without switching to an external PDF viewer or browser.

Typst's existing preview ecosystem is built around a browser-based frontend that consumes tinymist's reflexo vector IR format, a binary protocol with sub-page deltas, designed for the WASM renderer. Pulling that rendering stack into Zed would mean ~250 reflexo crates or shipping a WebView. Neither is appealing.

Background

tinymist's preview architecture has two halves: a compile pipeline (the LSP, comemo, incremental compilation, already running) and a render pipeline (reflexo vector IR to WASM frontend to browser canvas). The compile pipeline is the expensive part and it's already paid for. The render pipeline is what we need to replace.

Zed already has usvg + resvg in its dependency tree (from pdf_viewer). typst already has typst_svg::svg(page) which renders a compiled page to a complete SVG string. The gap is small: tinymist needs to call typst_svg::svg() instead of packing vector IR, and send the SVG string over the existing WebSocket data plane.

How other editors do it

VS Code uses tinymist's browser-based preview: a WebView panel loads the reflexo WASM renderer, which connects to tinymist's WebSocket and consumes vector IR. This works well but depends on WebView, which Zed doesn't have (and adding one for a single feature is heavy).

Neovim plugins typically shell out to typst compile --format pdf and display the result in an external viewer. This loses the live-update-on-keystroke experience.

Design

tinymist (native binary, already launched by the typst extension)
 |-- LSP: textDocument/didChange on every keystroke
 |-- comemo incremental compiler (~26ms recompile)
 |-- typst_svg::svg(page) -> complete SVG per page
 \-- WebSocket data plane on localhost:PORT
     \-- Text messages: page:{idx}:{total}\n<svg ...>

Zed (typst_viewer crate)
 |-- Sends tinymist.doStartPreview with --server-svg
 |-- Connects to WebSocket, sends "current"
 |-- Receives SVG text messages per page
 |-- Rasterises with usvg + resvg on background threads
 \-- Displays via GPUI img() in a scrollable multi-page pane

tinymist fork (1 commit)

Two new flags on the preview server, both opt-in:

--server-svg: the RenderActor calls typst_svg::svg(page) for each page and sends the result as WsMessage::Text instead of binary vector IR. Multi-page documents send one message per page with a page:{idx}:{total}\n header.

--strip-svg-glyph-defs: hash-based stripping of unchanged <defs id="glyph"> sections after the first frame. Typst SVGs embed every glyph outline as a <symbol>, typically 80-90% of the SVG size. When the glyph set hasn't changed (which is most keystrokes), this reduces per-frame transfer from ~2MB to ~200KB. Per-page hashing so multi-page documents don't cross-contaminate. Off by default because the client must cache and re-inject the stripped defs.

The existing vector IR path, browser-based frontend, and all default preview behaviour are untouched.

Zed side: typst_viewer crate

LSP integration. Finds the running tinymist server, sends tinymist.doKillPreview (per-file task ID for concurrent preview support) then tinymist.doStartPreview with --server-svg --strip-svg-glyph-defs --task-id=<path> --data-plane-host=127.0.0.1:0. Retry logic handles tinymist's config-reload dispose race (where workspace/didChangeConfiguration causes a project reload that kills the preview immediately after it starts).

Receive loop. Connects to the WebSocket data plane, receives SVG text messages, rasterises on background threads. Frame dropping via now_or_never drain of queued messages: during the ~80ms rasterisation window, stale intermediate frames are discarded. Per-page glyph defs caching: first frame's defs are cached per page, injected into subsequent stripped frames.

Multi-page display. Pages laid out vertically with ScrollHandle and scrollbar (same pattern as pdf_viewer). Visible-page-first rasterisation ordering: reads the scroll offset to prioritise the page the user is looking at, then expands outward to neighbours.

Workspace integration. OpenPreview / OpenPreviewToTheSide actions with keybindings. key_context + track_focus on the root div so workspace-level keyboard shortcuts route through the preview pane.

Performance

Benchmarked in release against a complex A4 2-column legal reference sheet (536 glyphs, 7704 glyph uses, 2566 text groups, ~2MB SVG per page, 5 pages):

                      avg      p50      min
compile (comemo):     26ms     26ms     25ms
rasterise (resvg):    82ms     83ms     80ms
total:               109ms    109ms    105ms

At 80 wpm (~150ms between keystrokes), the pipeline keeps up. Frame dropping handles bursts. For comparison, cold compile (no memoisation, i.e. tinymist compile CLI) is 538ms + 85ms = 624ms.

The benchmarks (bench_preview_lsp, bench_preview_loop) drive a real tinymist session: start the LSP over stdio, open the document, start the preview, send textDocument/didChange edits in a loop, receive SVGs over WebSocket, rasterise, measure.

Scope and known limitations

• Requires a forked tinymist (1 commit). The fork changes are designed to be upstreamable; both flags are opt-in and don't affect default behaviour.
• No viewport tracking. All pages are rendered and sent every frame. With comemo and frame dropping this is fast enough for typical documents, but very large documents (50+ pages) would benefit from only rendering visible pages.
• No scroll-to-cursor / click-to-source. tinymist supports these via jump/srclocation WebSocket messages, but we don't send or handle them yet.
• No reconnection on WebSocket disconnect. If tinymist restarts, the preview pane shows "Disconnected" and the user must reopen it.
• Debug builds are significantly slower (~560ms rasterise vs ~82ms release). This is resvg's expected debug/release performance gap.

Open questions

Should viewers be extensions instead of compiled-in crates?

Every viewer in Zed today (pdf_viewer, image_viewer, typst_viewer, markdown preview) is a Rust crate compiled into the binary. Each brings its own dependencies, its own GPUI view boilerplate, and its own protocol plumbing. The typst case makes the redundancy especially clear: the typst extension already launches tinymist, already manages the LSP lifecycle, already handles textDocument/didChange. The only reason the rendering lives inside Zed's binary is that extensions have no way to put pixels on the screen.

The WASM extension API can spawn processes, talk HTTP, run LSP, register slash commands. But it can't display an image. If the extension host exposed a frame buffer mechanism (extension creates a buffer, writes BGRA pixel data, presents it; host wraps it as a GPUI image and displays it in a pane), the rendering pipeline moves entirely into extensions:

• typst: the extension talks to tinymist (it already does), receives SVG (or pre-rasterised pixels), rasterises with resvg compiled to WASM (or receives pixels directly), writes frames to the buffer. The typst_viewer crate gets deleted from Zed.
• PDF: a Rust PDF renderer compiled to WASM. The extension owns the rendering. pdf_viewer crate deleted.
• images: trivial. Decode image, write pixels. image_viewer crate deleted.
• video playback: ffmpeg bindings in WASM, decode frames, write to buffer. This is the stress test for the design: 4K at 30fps is ~1GB/s of pixel throughput across the WASM boundary.
• Jupyter notebooks, plotting libraries, LaTeX preview, MJML email preview, Mermaid diagrams: all become possible as extensions without any changes to Zed's core.

The key design question is data transfer cost. At 4K (3840x2160x4 = 33MB per frame), memcpy across the WASM boundary matters. wasmtime's shared memory support may allow the host to map the WASM linear memory directly, avoiding the copy entirely. Alternatively, the host provides a buffer as a WIT resource handle, and the extension writes into it; the host reads it back without copying through WASM return values.

We're exploring this direction in a separate branch. This PR is the working-today approach that doesn't require extension API changes, but the goal is to make it obsolete.

Upstream tinymist

The fork is minimal. Is there interest in proposing --server-svg upstream? The multi-page framing protocol and glyph defs stripping are useful for any native editor integration, not just Zed.

Scale factor handling

Currently hardcoded to 2.0x. Should read the actual display scale factor from GPUI and pass it to the rasteriser.

Image sizing

Display dimensions are computed as pixel_size / 2.0. Should adapt to pane width like pdf_viewer does (fit-to-width with zoom).

Feedback welcome, especially from people who use typst and would benefit from live preview, or who have opinions on the extension-vs-crate question.

[dsturnbull]

output.mov

[ylu600]

This would be the final push I need to finally switch from VS Code to Zed.

[Flint6872]

Huge +1 for Typst rendering and custom viewer extensions in Zed.

To add to this, I've been working on a hobby project using GPUI to render Typst directly to a preview window. The core logic is in this crate: typst-gpui.

It's still an early proof of concept with some known translation limitations (e.g., circles are limited to 2-color gradients, and ovals show up as pill shapes, though PDF export works perfectly).

I don't have the time or deep expertise to integrate it into Zed myself, but someone familiar with Zed's preview architecture might find it useful as a reference or building block.

If Zed opens up custom viewers for extensions down the road, I'd love to try porting this over!