Results

GPUI Fast is Zed’s GPUI with its fast-path optimizations, as apps ship it. MyGo is a Go desktop framework, measured through its GPU-drawn native UI. Rune is built on Rust, wgpu, Taffy and Parley. Every figure on this page is read at build time from the run that scripts/build_site.py accepted, after it recomputed each median and range from the trials and checked them against the run’s summaries.

Heavy dashboard

A 1280×800 dashboard: 6 tiles, 30 cards of 26 sparkline bars, a status table and a log. Most values change 60 times a second; the table scrolls. 50 trials. Raw data

Text and a 100,000-row list

A streaming transcript beside a 100,000-row virtual list, updated 60 times a second. 41 trials. Raw data

Animation

48 blinking dots and a shimmering line of text, animated on every refresh of a 120 Hz display. 16 trials. Raw data

Variable-height list

100,000 chat rows of wrapped text, 1 to 8 lines each, about one in four with an image, in each framework's own list widget, which measures the rows: scrolled steadily, flung, and scrolled with a jump to a far row every half second. 50 trials. Raw data

How this was measured

• Machine: Apple M5 Max (Mac17,6, 18 cores, 128 GB), macOS 26.4 (25E246), AC Power.
• Displays: 2 × Studio Display XDR (3200 x 1800 @ 120.00Hz); the window on the main display, nothing covering it.
• Builds: zgx and GPUI Fast with their dist profile (dist (release, lto = "fat", codegen-units = 1)), rustc 1.96.0 (ac68faa20 2026-05-25); MyGo v0.6.3 (1524290, MIT) built with go1.27.3 darwin/arm64, go build -trimpath -ldflags=-s -w, cgo off; Rune at 998bef58 (dev, MIT), profile dist (Rune's perf with fat LTO and codegen-units 1), and a 14-line patch exposing its wheel path. Every framework uses the system allocator. zgx at c3c0dc9.
• Trials: each a fresh launch, the first 5 s discarded and the next 10 s sampled every 50 ms; 3 trials of each mode, in alternating order, and 1 more of any whose CPU or GPU spread past 10% of its median; idle 2 times in the dashboard, 20–30 s after launch. Every trial had to run as long as asked, at 60 updates a second. Medians are shown, the trials' range beside them. Frame timing is 3 separate 8 s captures of each mode.

How Rune is driven

• Ticks through AppHandle::update_if. Rune's per-frame poll, woken by wake_after, ran on frame boundaries up to 16 ms late and dropped about 5% of ticks. A timer thread now hands each tick to the UI thread through update_if, Rune's API for a timer or feed, and waits for it to run, as the other adapters' loops do. This changes the measurement: Rune now does the same 60 ticks a second of work as the others.
• Updates apply at once (Tx::instant). Rune animates every layout and colour change on a 0.3 s spring by default. Each tick is applied instantly, as the other frameworks apply live data. Leaving the springs on would add animation frames the other frameworks don't draw.
• sRGB blending (App::srgb_blend(true)). Rune blends translucency in linear light by default, so 10% opacity looked brighter than in the others. Its documented sRGB mode matches CSS and the other three. It is a surface format and a shader flag, with no extra pass, so it changes pixels, not cost.
• Heavy's panel contents sit 1 pt in. A Rune border takes no layout space, while CSS, which the scene's geometry follows, places absolute children inside the border. The children are offset by the border's width so that everything lands on the same pixels. Geometry only; the cost doesn't change.
• vlist scrolls through a small patch exposing Rune's own wheel path (rune-wheel.patch, 14 lines). Rune's public API can't set a vertical scroll offset, and only user wheel input moves a list. The patch adds Tx::wheel, which feeds the same Runtime::wheel_xy a real wheel event goes through, at once, between frames. Nothing else in Rune changes. This is what makes Rune's scroll and fling measurable; it adds no work of its own.
• Jump reveals the row (nearest), not at the top. Rune's scroll_into_view scrolls just far enough to show a row, where the other adapters put the jumped-to row at the top. A jump still mounts and lays out the far rows, but the row lands at a different place in the viewport.
• Rune's window isn't colour-matched by the window server. Its Metal layer is untagged (wgpu 30's default, which Rune keeps), so sRGB values reach the display unconverted and look slightly more saturated. The window server converts the other three, whose layers are tagged sRGB. Rune may skip that colour-matching work, which could lower its WindowServer cost. Kept as Rune ships it.
• The vlist probe runs headless. Row heights are read from Rune's headless runtime, with the same font and 720 pt width, after revealing each row. A row's height doesn't depend on where it sits. Only the layout check uses this; it doesn't feed any measured figure.

What each figure is

• CPU: the app process’s CPU time over the sample, as a percentage of one core (it can exceed 100).
• WindowServer CPU: the CPU of macOS’s compositor, which puts every app’s frames on screen, over the same sample: what showing the app costs the system beside the app’s own CPU. It includes what WindowServer does anyway.
• GPU power: the whole GPU’s energy over the sample, from the system’s energy model (IOReport), in milliwatts, less the desktop alone (measured each repeat). It counts everything the GPU does for the app, the window server’s compositing of its window included, so a framework is charged for how it presents its frames as well as for drawing them.
• App GPU time (secondary): the GPU time macOS accounts to the app’s process, as cycles at the GPU’s mean clock. It includes the time from each submission to the GPU starting it, so an app that draws small frames often reads high. Kept for comparison with earlier runs.
• Frame time: the 99th percentile of the intervals between frames shown on screen; at 60 updates a second, 16.7 ms is on time (8.3 ms for the animation, drawn at 120 Hz). Long frames are intervals over 25 ms.
• Unfilled rows (the list): the window captured 10 times a second while scrolling and jumping; a capture counts when a stretch of the rows’ padding over 24 points shows the window’s background, where no row was drawn.
• Memory: the process’s physical footprint (what Activity Monitor shows: resident memory plus GPU memory it owns), averaged over the sample.

Caveats

• Compare within this run only: the same binaries measured hours apart read differently, so a cell is not comparable across runs, while the frameworks in one run share its session.
• Idle memory is two-level: an idle window settles at one of two levels about 25 MB apart, launch to launch, as the Metal driver returns its startup memory. Read idle memory with its range.
• MyGo is immediate mode: each frame it draws builds and draws its whole window, which is how MyGo apps work.
• Binary size is not compared.
• One machine, one session; a personal Mac in use, other applications kept running (the run waited until the machine was quiet). Windows and Linux are not compared here.

The full protocol, its noise and every other series are in the methodology. The numbers themselves: data.json, data.csv, and every trial under docs/results.