Sequence Viewer performance

Sequence Viewer automatically limits mounted residue elements for long sequences and many-row alignments. Try representative workloads here, then use the measured results and limits below to decide whether residue-level rendering fits your application.

Available in Sequence Viewers 2.2.0. This demo uses the published npm package. Read as Markdown · Sequence Viewer API and examples

Try a workload

Choose a preset and render it. The viewer switches to windowed rendering when the longest sequence length multiplied by the row count exceeds 5,000 cells. The demo uses synthetic DNA rows with deterministic mismatches introduced after the first row; it tests viewer behavior, not biological alignment quality. Scroll inside the viewer to watch the mounted residue count change while the complete logical input stays available for selection, copy, annotations, and download.

Click the green synthetic annotation to select its complete coordinate range, or drag across residues. For keyboard selection, enter start and end positions in the range controls below the viewer. Coordinates are zero-based and include both endpoints. These controls use the same full-coordinate selection state, including ranges outside the mounted viewport.

What windowing changes

For smaller workloads, Sequence Viewer uses its ordinary wrapped layout. Above 5,000 logical cells, it divides coordinates into wrapped blocks, flattens each block into physical sequence and annotation lines, and mounts only the lines near the visible viewport. Up to three extra lines on each side remain mounted to keep scrolling smooth.

Windowing changes the amount of mounted DOM. It does not discard data or change coordinates. Selection, copied sequence text, mismatch highlighting, annotations, and downloaded FASTA still operate on the full input. Resizing preserves the leading visible coordinate as line wrapping changes. The same behavior works when the page scrolls and when the viewer sits inside a scrolling container such as the demo above.

Measured workloads

The measurements below compare the published 2.1.0 baseline with a packed 2.2.0 development build (166da64), before the final viewport fixes. They have not been rerun against the final 2.2.0 release used by the live demo. They are medians of three runs in headless Chromium with a fixed viewport and no CPU throttling. Treat them as comparative evidence from one machine, rather than timing guarantees for every browser or device.

These results were recorded on an Apple M4 with 16 GiB RAM, React 18.3.1, headless Chromium 140.0.7339.16, a 1100 × 900 viewport, and no CPU throttling. The fixtures contain no annotations. Mount excludes network and module loading; selection dispatches a synthetic first-cell mouse event and waits for rendering. Candidate selection counts only mounted cells because offscreen selected cells intentionally have no DOM node. Candidate DOM counts every element in the benchmark fixture document, while the interactive demo counts only mounted residue elements inside the viewer, so those two numbers are not directly comparable.

The raw TanStack report and reproduction guide are pinned at the commit that recorded them. The report identifies performance implementation 166da64 as its clean source. That implementation predates the final viewport fixes and removal of two small-grid DOM wrappers per coordinate. The interactive demo reports mounted residue elements, not a synthetic timing, because live timing changes with the browser, device, extensions, and current load.

Capacity and limits

Input storage and sequence preparation still grow with the total supplied residues plus annotation coverage. Windowing bounds mounted residue elements around the viewport; it does not make a 100 kb sequence or a large alignment constant-memory work.

Use Sequence Viewer when people need residue-level inspection and selection. For chromosome-scale sequences, start with an overview or region picker and mount the residue viewer for the chosen interval. For very large alignments, page or filter rows when the complete matrix does not need to be inspected at once. There is no universal hard limit: annotation density, row count, device memory, container size, and host rendering work all affect the result.

The virtual layout measures a monospace residue glyph and assumes each residue column has a stable width and line height. Keep residue classes geometry-neutral: color, background, and text decoration are safe choices. Avoid per-residue font-size or font-family changes, padding, margins, transforms, or other styles that change width or line height.

Server rendering emits a bounded initial window for large inputs. Hydration measures the real container and glyph size, then updates the visible window. This avoids serializing the full residue DOM, while the full input still reaches the client as application data.

Integration guidance

No performance props are required. Existing applications receive windowing automatically after updating to 2.2.0; the public SequenceViewer props and zero-based coordinates stay the same.

<div style={{ maxHeight: 520, overflow: "auto" }}>
  <SequenceViewer
    sequences={sequences}
    annotations={annotations}
    selection={selection}
    setSelection={setSelection}
  />
</div>

Give a long viewer a bounded scrolling container when it should not expand the entire document. In 2.2.0, residue and annotation interactions are pointer-driven. For keyboard selection, provide labeled start/end inputs and a visible selection summary connected to controlled selection state, as in this demo. Provide a separate labeled text or table representation when sequence content must be available to assistive technology.

The renderer has automated coverage for viewport window changes, offscreen logical selection, nested and page scrolling, resize anchoring, and bounded server output. The interactive documentation is validated in Chromium. The package's published browser floor and complete API remain documented on the Sequence Viewer page.