← product evidence + the ladder to state of the art

Nishi browser — the paint-cliff and big-page fixes (eaglercraft + full Wikipedia now load)

workstream: S21 experiential / S18 graphics — browser chrome-parity ratchetrun: browser-perf-2026-07-162026-07-16

Verdict: Two hard blockers eaten — and one honest limit made visible. (1) PAINT CLIFF: the Eaglercraft page went from >170s (killed, never finished) to 2s — root cause was every CSS lookup scanning the whole computed-decl array per box per ancestor (O(boxes x ancestors x ncomp)); fixed with a per-box decl index, proven a PURE accelerator by a gate (same answers on every box x 4 resolvers, buckets bounded). (2) BIG-PAGE FETCH: the full Wikipedia /wiki/Computer article returned ZERO bytes (the fetch response buffer capped at 512KB, the page is ~1MB); raised to 4MB across the fetch/dechunk/charset/GUI buffers — it now fetches 966,758 bytes and renders a 27,465px page in 3s. THE HONEST LIMIT: Eaglercraft is a 100 percent JS/WASM app, so with the hang gone the Nishi browser paints its background and NOTHING ELSE (the launcher you see in Chrome is drawn entirely by scripts the Nishi engine does not execute yet). So this run proves the paint cliff is dead (by TIMING + a gate), not that we render the launcher. The real VISUAL proof of the paint fix is the Wikipedia render below.
evidence
Eaglercraft launcher — Chrome (left, full launcher) vs Nishi (right, blank dark page). This is the honest picture: Eaglercraft is entirely JS/WASM, so the Nishi browser correctly fetches, lays out and paints in 2 seconds (was an infinite hang) but there is no static content to show — the launcher is 100 percent script-drawn and the Nishi engine does not run page scripts yet. The paint-cliff win is real but it is proven by the 2s timing and the equivalence gate, NOT by these pixels. open full size
evidence
Full Wikipedia "Computer" article, first screen, rendered by the Nishi browser — THIS is the visual proof of both fixes. The page previously could not load at all (fetch returned 0 bytes at the old 512KB cap); it now fetches ~1MB and the paint index lets it lay out 27,465px of real article (body text, headings, links) in 3 seconds instead of hanging. open full size

Measured

whatresultmeaning
Eaglercraft paint time>170s (killed) -> 2sPer-box computed-decl index (br_cidx): CSS lookups scan only that box's bucket, not the whole array
Index correctnessnx_cidx_equiv_gate GREEN300 boxes x 4 resolvers (bg/border/color/font-size): bucketed answer == full-scan answer, 0 divergences; can-fail control confirms buckets are genuinely bounded (max 9 vs ncomp 667)
Wikipedia /Computer fetch0 bytes -> 966,758 bytesResponse/dechunk/charset/GUI buffers 512KB/1MB/2MB -> 4MB uniformly
Wikipedia /Computer render27,465px page in 3sThe largest real page the engine has laid out; no hang, no truncation
Regression check203KB baseline page unchanged (203,464 bytes); bg-cascade + fontsize-frac + inline-vec-measure gates all GREENThe buffer + index changes are additive; every prior gate re-run passed
honest gapEaglercraft game UI (JS/WASM) not executedStatic-shell paint only; JS execution is a separate, larger arc (the engine has a JS VM but the browser does not yet run page scripts in the shot lane)

Machine detail: api.json · related: /evidence/nishi-browser