From 3da0f2e2f624bb52db7470c036122db66b548817 Mon Sep 17 00:00:00 2001 From: iris <2+iris@noreply.localhost> Date: Sun, 30 Aug 2026 20:35:54 -0400 Subject: [PATCH] Replace a claim measured through the software rasteriser Two places said the history cushion's evidence was a swipe that moved nothing for 689ms. That reading came from `ui-trace show` on a row taller than the viewport, which reports clipped bounds and so prints "nothing moved" for a list that is scrolling fine -- and it was taken on the software renderer besides. The finding it supported is sound and has a better witness: counted at the server, ten swipes asked for ten pages before the change and three after, which does not depend on how anything renders. Also records what the screen actually costs now, measured on the GPU emulator: 5.2-5.9% janky frames and 0-2 slow UI-thread frames flinging fast, against 3.3% for the stock Settings app on the same device. With the note that matters for repeating it -- let the screen settle before resetting gfxinfo, because the first seconds after opening a session are every row being composed for the first time and read three times worse. Co-Authored-By: Claude Opus 5 --- AGENTS.md | 21 ++++++++++++++++--- .../kotlin/com/example/aiapp/SessionScreen.kt | 8 ++++--- 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 6483e52..9207431 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -477,9 +477,24 @@ machine belongs in `~/.claude/TOOLCHAIN.md` (toolchain versions) or rows has to measure a screen rather than name a number: the history cushion was eight rows, which on a tool-heavy transcript is less than one screenful, and the reader hit the end of what was loaded on every swipe - and stood there for a round trip. That was "scrolling is laggy" -- not a - slow frame. It is `HISTORY_SCREENS` viewports now, counted from what is - actually on screen. + and stood there for a round trip. It is `HISTORY_SCREENS` viewports now, + counted from what is actually on screen. Measured at the server, which is + the one number here that does not depend on how the emulator renders: + against a 24,000-event transcript, ten swipes asked for ten pages before + and three after. +- **What the transcript screen costs to scroll, for whoever measures it + next.** Taken 2026-08-30 on the GPU emulator (`emu up` provides one; a + frame number from the software rasteriser means nothing -- see + `~/.claude/MACHINE.md`), against a real imported transcript with the debug + server at `--delay 120`. Settled and flinging fast, both into fresh + history and back through rows already drawn: **5.2-5.9% janky frames, 99th + percentile 29-32ms, 0-2 slow UI-thread frames.** The stock Settings app on + the same device is 3.3% and 38ms, so this is at the platform floor and + what is left is the emulator rather than the app. The number that is *not* + at the floor is the first few seconds after opening a session, where every + row on the way is being composed for the first time; that is inherent to a + lazy list and it is why a measurement taken before the screen settles + reads three times worse. **Settle first, then reset `gfxinfo`.** - **Only `fetchTranscript` was off the main thread; the fold was not.** `foldEvent` returns a new list per event, so a page is that many copies of a growing list -- fine at 80 events and about 300,000 element copies at diff --git a/app/androidApp/src/main/kotlin/com/example/aiapp/SessionScreen.kt b/app/androidApp/src/main/kotlin/com/example/aiapp/SessionScreen.kt index 3f88bf9..1462ddc 100644 --- a/app/androidApp/src/main/kotlin/com/example/aiapp/SessionScreen.kt +++ b/app/androidApp/src/main/kotlin/com/example/aiapp/SessionScreen.kt @@ -88,13 +88,15 @@ private val LOADING_SPINNER = 48.dp * row is anything from one line to a page and a fixed count is therefore a distance only by * accident. Eight rows was the number, and on a tool-heavy transcript eight rows is less than one * screen: the reader reached the end of what was loaded on *every* swipe and waited a round trip - * standing there. That is what "scrolling is laggy" turned out to be -- not a slow frame, but the - * list running out of transcript, which the emulator showed as a swipe that moved nothing for 689ms - * and then jumped. + * standing there, which is a list running out of transcript rather than a slow frame. * * Three, so a fling lands on rows that are already there and the page after them is on its way. The * cost of being generous is a page fetched that nobody reads; the cost of being mean is a list that * stops under a finger, and those are not the same size. + * + * Counted at the server rather than inferred from the screen, which is the only measurement here + * that does not depend on how the emulator renders: against a 24,000-event transcript at `--delay + * 120`, ten swipes asked for **ten** pages before this and **three** after. */ private const val HISTORY_SCREENS = 3