---
title: "Stadium and arena renderer performance"
description: "200,000 seats chart-ready in 1.95 s at 57.6 FPS zoom, a 999 ms observation at 53,018 seats, and dated renderer and 3D benchmarks with their methods."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.seatlayer.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://app.seatlayer.io/demo/play/century-stadium-200k) and the [100,000-seat arena demo](https://app.seatlayer.io/demo/play/century-arena-100k).

## 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.**

| Venue fixture | Chart ready | Zoom | Pan |
| --- | --- | --- | --- |
| 100,000 seats | 1.02 s | 58.6 FPS | 60.0 FPS |
| 150,000 seats | 1.44 s | 58.6 FPS | 60.0 FPS |
| 200,000 seats | 1.95 s | 57.6 FPS | 60.0 FPS |

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](https://github.com/seatlayer/seatlayer-performance),
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](https://app.seatlayer.io/demo/play/century-stadium-200k) and a
  [100,000-seat arena demo](https://app.seatlayer.io/demo/play/century-arena-100k) 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](/platform/concurrency-performance/)
  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.

| Observation, 14 September 2026 | Displayed chart-ready time |
| --- | --- |
| Owner-supplied production Chrome screenshot | **999 ms** |
| Separate desktop session: first visit | 6.2 s |
| Same session: first normal reload | 5.9 s |
| Same session: second normal reload | 3.7 s |

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.

| | |
| --- | --- |
| Measured | 27 August 2026, commit `84380e3b` (fixture waits for the progressive reveal to finish before probing) |
| Machine | Apple Silicon laptop, Chromium via Playwright, 1280x800, foregrounded window, load average ~4 |
| Fixture | `e2e/fixtures/renderer-13k-benchmark.html?venue=mega` (53,018 seats) against `?venue=uber` (13,784 seats) |
| Spec | `e2e/renderer-50k-benchmark.spec.ts` |

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.

| Measurement | 13,784 seats | 53,018 seats |
| --- | --- | --- |
| Venue on screen | 182 ms | 348 ms |
| Every seat drawn | 1,630 ms | 4,260 ms |
| JS heap | 53.5 MB | 121.9 MB |

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.

| Interaction | 13,784 seats | 53,018 seats |
| --- | --- | --- |
| Flat-to-3D transition | 17.7 ms · 58 FPS | 34.2 ms · 49 FPS |
| Focus a section | 17.7 ms · 59 FPS | 17.3 ms · 54 FPS |
| Pan, focused | 17.6 ms · 60 FPS | 17.4 ms · 60 FPS |
| Zoom, focused | 17.6 ms · 55 FPS | 17.6 ms · 46 FPS |
| Selection burst of 32 seats | 17.7 ms · 60 FPS | 17.6 ms · 52 FPS |

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

```bash
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.

Source: https://docs.seatlayer.io/platform/renderer-performance/index.mdx
