epic(perf): steady 120 Hz without drops (profile findings, Sep 2026)

[ZhuchkaTriplesix]

Goal

Steady 120 Hz without drops (and headroom for 144 Hz): every frame ≤ 8.3 ms build and ≤ 8.3 ms raster, no multi-frame hitches on common actions.

How it was measured

Profile builds on Linux (Hyprland, 120 Hz monitor, AMD iGPU, Impeller GLES), two harnesses added in this investigation:

• benchmark/app_perf_bench.dart: the real shell driven through the Demo Playground with a throwaway data directory and in-memory secrets. Scenarios: idle, sidebar toggle, run a 5000-row query, grid vertical / horizontal scroll, hover, typing, tabs, connections tree with 1500 tables (expand / scroll / collapse). Reports FrameTiming, presented-frame intervals from the raster timeline, and optionally CPU profile, allocations and engine timeline per scenario.
• benchmark/grid_perf_bench.dart: the grid alone (5000×120), modes scroll, edit, select, dialog, rerun.

Caveats found along the way: recording the Dart timeline stream allocates heavily inside the framework and inflates GC; the in-process VM service client itself costs CPU; FrameTiming.buildDuration does not include flushSemantics.

Results (real app, window 2056×2616)

Scenario	build p50 / max	raster p50	Verdict
Idle	nothing drawn	—	ok
Sidebar toggle	4.0 / 7.1 ms	0.8 ms	too heavy for 144 Hz → #984
Run 5000-row query	— / 54–75 ms	1.0 ms	one big hitch → #982, #981
Grid vertical scroll	1.4 / 3.4 ms	0.8 ms	ok
Grid horizontal scroll	0.1 / 12–20 ms	0.8 ms	window-shift hitches → #983
Hover over grid	0.1 / 0.3 ms	0.8 ms	ok
Typing in editor	2.6 / 5.0 ms	0.9 ms	ok
Tab switch	— / 6.8–7.9 ms	0.9 ms	tight → #985
Tree 1500 tables: expand / scroll / collapse	≤ 5.9 / ≤ 2.8 / ≤ 1.8 ms	1.2–1.3 ms	ok

All scenarios present at exactly 60 fps on Linux regardless of cost → #980 (engine).

Children

• perf(linux): app is capped at 60 fps because the GTK embedder has no vsync #980 Linux capped at 60 fps (GTK embedder has no vsync; upstream Use vsync in Linux embedder flutter/flutter#192342)
• perf(grid): semantics tree is rebuilt for every visible cell (~17 ms per result set, hidden from FrameTiming) #981 Grid semantics rebuilt per cell (~17 ms per new result set, hidden from FrameTiming)
• perf(grid): first frame of a new result set spends ~35 ms in layout #982 Grid first frame of a new result set: ~35 ms layout
• perf(grid): column-window shift during horizontal scroll builds heavy cells (12-50 ms frames) #983 Grid column-window shift builds heavy cells (12–50 ms)
• perf(shell): sidebar toggle re-lays out offstage workspace layers and LayoutBuilders every frame #984 Sidebar toggle lays out offstage layers and LayoutBuilders every frame
• perf(workspace): switching SQL tabs builds up to 8 ms in one frame #985 SQL tab switch up to 8 ms build

Already fixed in this cycle: #875, #879, #885, #972 (grid rebuilds), #874, #876, #877, #878, #886.

Related

#723 (connections tree @ 120 Hz: measured within budget with 1500 tables), #739 (QA sign-off).

[ZhuchkaTriplesix]

Status update — 2026-09-27

Went through all six children this cycle. Summary of what shipped, with measured before/after where it exists, and honest notes on where a fix didn't move the needle or wasn't attempted at all.

Closed

• perf(grid): semantics tree is rebuilt for every visible cell (~17 ms per result set, hidden from FrameTiming) #981 grid semantics rebuilt per cell — fixed.
• perf(grid): first frame of a new result set spends ~35 ms in layout #982 grid first-frame layout cost — partial: shipped column-width caching. Measurable but modest improvement; the deeper fix (custom RenderObject / row-batch renderer) was scoped out as higher-risk than warranted for the remaining gain.
• perf(grid): column-window shift during horizontal scroll builds heavy cells (12-50 ms frames) #983 grid column-window shift builds heavy cells — partial: shipped grid-level tap/double-tap/cursor hit-testing (removes a GestureDetector+MouseRegion per visible cell). Benchmarked (grid_perf_bench.dart MODE=select, 5000×120): build p50 3.53→2.88ms, total p50 11.69→9.09ms, frames>8.33ms 312/372→264/371. Secondary-tap/context-menu/tooltip hoisting and a full custom-RenderObject rewrite remain out of scope.
• perf(workspace): switching SQL tabs builds up to 8 ms in one frame #985 SQL tab switch build cost — fixed (VerticalSplitPane caching, from earlier in this cycle).

Still open

• perf(shell): sidebar toggle re-lays out offstage workspace layers and LayoutBuilders every frame #984 sidebar toggle — partial: shipped LazyOffstage, which skips re-laying-out hidden QueryaSwitchingBody layers every animation frame (verified correct with a dedicated test). Benchmarked honestly: no measurable difference in the bundled sidebar_toggle scenario (build p50 3.5ms before/after), because the dominant cost there is the visible tree's own LayoutBuilder rebuilds reacting to the changing width, not the hidden layer's layout. That remaining piece needs restructuring _MainContentSplitState so the workspace's laid-out width doesn't change during the toggle at all (reserve final width immediately, animate the reveal via clip/transform) — a bigger, riskier change to a central screen (main_screen.dart), not attempted yet.
• perf(linux): app is capped at 60 fps because the GTK embedder has no vsync #980 Linux capped at 60fps — not attempted. Root cause is the GTK embedder having no vsync (upstream flutter/flutter#192342), which is likely an engine/embedder-level issue rather than something fixable from app code. Worth a scoped investigation before committing effort, but that investigation hasn't happened yet.
• epic(perf): Connections sidebar FPS / frame budget @ 120 Hz #723, qa(motion): Fluid shell + connections tree DevTools sign-off @ 120 Hz #739 — tracking/QA sign-off issues, not independent code fixes; epic(perf): Connections sidebar FPS / frame budget @ 120 Hz #723 already notes the connections tree measured within budget at 1500 tables.

Net effect

Every scenario in the original profile table has a closed or measurably-improved issue against it except the sidebar toggle (partially improved, real bottleneck untouched) and the Linux vsync cap (untouched, may not be fixable here at all). Given the remaining work is either high-risk-for-uncertain-gain (#984's Row restructure) or possibly not our issue to fix (#980's embedder cap), pausing here rather than continuing to grind on partial increments — flagging both for a deliberate decision on whether/how to pursue them next.