Stadium and arena renderer performance

SeatLayer supports large arena and stadium buyer experiences with reusable decks and sections, progressive rendering, viewport detail, and complete 2D selection with optional 3D on the same inventory. Evaluate a 50K-plus venue using the public 53,018-seat stadium and 13,784-seat arena demos, and read the 100,000- to 200,000-seat fixture benchmark below. This page separates the stadium-scale run and the latest picker-readiness observation from dated interaction and GPU benchmarks, with the method and limits for each.

Historical run, 27 August 2026: at 53,018 seats the buyer renderer measured 17.6 ms p95 frames while panning, zooming and selecting in this desktop run. The venue is on screen in 348 ms and every seat is drawn within 4.3 s while it stays interactive; the flat-to-3D transition measured a 34.2 ms p95 frame.

Open the chart and test it yourself, no signup: the 200,000-seat public demo and the 100,000-seat arena demo.

September 2026 stadium-scale benchmark

On 15 September 2026, public 100,000-, 150,000- and 200,000-seat venue fixtures were benchmarked against a local production build. 200,000 seats were chart-ready in 1.95 s with 57.6 FPS while zooming and 60.0 FPS while panning.

Method: medians of three runs per fixture, desktop Chrome 152, 1280 × 720 viewport at devicePixelRatio 2, against a local production build. The fixtures, the full run log and SHA-256 fixture manifests are published in the open, MIT-licensed seatlayer-performance repository, so the run can be reproduced without trusting this page.

This section is the canonical method target for the “benchmarked at 200,000 seats” claim wherever it appears.

What this run does not publish:

• No live-URL measurement. These are local production-build runs. They do not include the network fetch of a 200,000-seat chart from the live API, so they must never be quoted as what app.seatlayer.io does. A 200,000-seat public stadium demo and a 100,000-seat arena demo are open live; their timing varies by device, network and run and is not this benchmark.
• Concurrency is measured separately. Renderer evidence does not establish concurrent buyer or event capacity. See the single-event concurrency benchmark for the 10,000-simulated-concurrent-buyer workload, the delivery of all 400,000 expected hold updates to 10,000 connected viewers, and the scope of that isolated test setup.
• No hard venue ceiling. 200,000 seats is the largest fixture measured so far, not a maximum. Validate an unusually large venue with your own chart.

September 2026 live demo observation

On 14 September 2026, an owner-supplied screenshot of the public 53,018-seat stadium demo recorded chart ready in 999 ms (approximately one second). Three separate checks in a desktop Chrome session displayed 6.2, 5.9 and 3.7 seconds. These are picker-readiness observations, not full-page load or complete-seat-reveal measurements; results vary by run and device.

The separate session used Chrome on macOS 26.6.2 with a visible desktop viewport captured at 1920 × 1059. Cache state and machine load were not controlled. The screenshot does not establish the owner’s hardware, exact browser version or deployed commit. The table preserves all observed results; it is not a controlled before/after benchmark or a one-second service guarantee.

The demo reads chart_rendered.renderingTimeMillis from the picker. Its timer starts inside render(), after the page has obtained the chart, and uses a local demo inventory transport. It excludes earlier page navigation, application download and chart retrieval, and does not wait for every individual seat to finish its progressive reveal. Consequently, 999 ms chart ready cannot be compared as a speedup against the older 4,260 ms every-seat-drawn milestone.

A supported short description is: “The public 53,018-seat stadium demo recorded approximately one-second picker readiness in a desktop observation.” Cite this section with that statement so the date, run variation and metric remain available. The interaction and GPU figures below retain their original dates; they were not remeasured in September.

Historical August 2026 method

The run compares two published charts on the same machine in the same session, so the second column is a scale comparison rather than a lone number.

Two details in that row do the real work. The window is foregrounded, because a hidden tab freezes requestAnimationFrame and a background run measures a renderer that is not drawing. And the fixture waits for every seat to land before it probes. Probing mid-reveal measures the reveal, not the renderer.

Historical August 2026 numbers

The chart is progressive, so readiness has two milestones: the venue is usable when its sections are on screen, and every individual seat lands after that without the map going unresponsive in between.

Interaction is reported as the 95th-percentile frame duration and the frame rate recorded by the probe. The FPS value is a separate observation, not a mathematical conversion of the p95 duration. p95 exposes the slower end of the recorded frames that a mean can hide.

The p95 frame is flat across a 3.8x difference in seat count for every interaction except the flat-to-3D transition, which is the one moment the whole venue is rebuilt in a new projection. What scales is the one-off cost of drawing every seat, and the resident memory, not the cost of a frame once the chart is up.

Historical 3D GPU measurement

A separate headed Chromium run on 4 August 2026 measured the interactive 3D venue view on an Apple M3 Pro through ANGLE’s Metal renderer. In that one desktop experiment, both the 14,142-seat arena and 53,018-seat stadium recorded 60 FPS at p50, p05, and minimum during a sustained orbit drag and a scripted fly-to-seat descent through the chair LOD band. Draw calls remained 3 while idle and 4 in flight at both sizes.

That result belongs to the specific M3 Pro/Metal run and the two scripted interactions in e2e/view3d-50k-benchmark.spec.ts; it is not a universal 60 FPS claim, a mobile result, or a guarantee for other GPUs and venues. These figures are transcribed from SeatLayer’s archived 4 August engineering measurement, rather than a new run. The archived fixture and current public demo can differ; the public 53,018-seat chart above is available for evaluating your own browser and device.

What this run does not publish

Camera-glide numbers measured while the progressive seat reveal was still running are not published; the fixture now waits for every seat before probing (an earlier same-day run mid-reveal showed 150-349 ms frames, which measured the reveal, not the renderer).

The viewport-culling probe reports 0 culled section groups at the 53,018-seat focus endpoint on this build and on the previous day’s build alike; the fitted camera for a stadium-sized section stays below the live-seat threshold, so the venue paints from the cached overview bitmap there. Frame timings above are unaffected; the probe needs a zoomed-in endpoint to count culled groups.

No maximum seat count is published either. 53,018 is the largest chart measured, not a ceiling, and these figures describe the buyer renderer rather than an end-to-end authoring session. The machine and build are stated above precisely because a number without them is not reproducible; validate an unusually large or unusual venue against your own chart.

How to reproduce

pnpm exec playwright test e2e/renderer-50k-benchmark.spec.ts

The spec drives both fixtures, waits for the reveal to settle, records short probes for each interaction, and prints the same tables. Run it foregrounded on a quiet machine; a laptop under load, a hidden window, or a probe that starts before the reveal finishes will not reproduce these numbers.