zgx uses the least CPU in 10 of 10 tests and the least GPU power in 9, against GPUI Fast, MyGo and Rune.

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. Raw data

Text and a 100,000-row list

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

Animation

48 blinking dots and a shimmering line of text, animated on every refresh of a 120 Hz display. 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. Raw data

Microbenchmarks

One state change, and one scroll step of 10,000 rows, timed headless in process CPU per operation (the median over batches after a warm-up) from the change through to a frame ready to present. Each framework's frame is compared with the frames that do the same work: GPUI Fast's headless frame stops before the GPU encode, so it sits beside zgx's frame without one; Rune's and MyGo's include it (MyGo's also rasterizes on the CPU), beside zgx's with it. How they are defined

• The change alone ("write") is not compared: GPUI Fast, Rune and MyGo store the value and mark the window to draw (0.02–0.14 µs), leaving all their work to the frame, where zgx's bindings update their nodes as the value is set (about 1–8 µs). The frame is the figure that counts, and it includes the write.
• MyGo's frame rasterizes its scene on the CPU, as its headless tester does, where a window would draw on the GPU; it is shown at a raster scale of 0.05× (the charts' MyGo), which leaves its layout and paint and makes the raster almost free (at 1×: state update 468 µs, scroll step, fixed rows 481 µs, scroll step, variable rows 976 µs).
• Most of a frame with the GPU encode is what any Metal frame costs: a bare Metal frame (a command buffer, one empty render pass, commit) takes 44–94 µs of process CPU back to back on this Mac, most of it in Metal's own threads; zgx's work over it is the few microseconds of its frame without the encode and about 33,000 instructions of drawing and presenting.

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 (release, fat LTO, one codegen unit), 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) (Rune's own bench scripts use perf), and a 14-line patch exposing its wheel path (see below). Every framework uses the system allocator. zgx at 1cd5211.
• Trials: each a fresh launch, the first 5 s after its window was ready (frontmost and uncovered) 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 its window was ready. 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.
• 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 (the desktop alone, measured each repeat, is beside each chart's title).
• 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; beside each chart's title). 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, about half a millisecond after the GPU idles, so an app that draws small frames often reads high: measured with Metal System Trace, zgx's animation frames execute in 46 µs against GPUI Fast's 318 µs, yet this counter charges zgx more. It also moves with whatever else keeps the GPU awake. 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 for 8 s in 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.
• The list widgets: zgx's measured virtual list, the same list from a Luau script (ui.list { measured = true }), and GPUI Fast's list measure each row as they lay it out; MyGo's ui.List keeps its place by an anchor row and estimates unmeasured rows at the average height; Rune's virtual rows estimate unmeasured rows (28 pt fixed, a three-line row variable) and measure as they mount.

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.

Caveats

• Since 2026-10-26 a trial’s sample starts from its window being ready (frontmost and uncovered, polled up to 2.5 s), not from its launch, and each app runs 3 s longer; this run is therefore not ranked against earlier ones, which measured from launch.
• Compare within this run only: the same binaries measured hours apart read differently (the machine's state changes), 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. Which level a launch lands on is the driver's timing, not the app's, so 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.
• WindowServer spends more CPU on zgx’s window than on the cheapest rival’s in 9 of 10 tests, by at most 0.8 points of a core (its chart follows CPU in each scene).
• GPU power is within the trials’ spread, or higher for zgx, in: animation (animating) against MyGo.
• Until 2026-10-25 these pages' GPU figure was app GPU time; it is now GPU power, which measures what the GPU spends rather than how long it was held (see How this was measured). In the animation, zgx uses 24% less than GPUI Fast, 2% less than MyGo, 48% less than Rune on app GPU time and 17% less than GPUI Fast, 5% more than MyGo, 59% less than Rune on power.
• No app exited abnormally during the run.
• 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.

Data

• This page's numbers: data.csv, data.json, and the microbenchmarks’ micro.jsonl.
• Every trial, raw:
  • docs/results/suite-macos-2026-10-26-1cd5211/heavy (52 trials, 36 pacing captures)
  • docs/results/suite-macos-2026-10-26-1cd5211/lab (45 trials, 36 pacing captures)
  • docs/results/suite-macos-2026-10-26-1cd5211/animate (15 trials, 12 pacing captures)
  • docs/results/suite-macos-2026-10-26-1cd5211/vlist (54 trials, 45 pacing captures)
• How the runs are made: benchmarking; the adapters: comparisons; the code: github.com/zeronsh/zgx.