b3cebd0f4c2d22136f432a9e033c81863ddd97e5
Three faults, all in how the outer bound behaved, and all of them mine. **It was a destination.** Rows were stood up towards it a couple at a time until the window was the full sixteen screens, whether or not anybody was going to read them. Two rows is not a bounded amount of work -- a row here runs to twenty-five screens of markdown -- so the transcript was laying text out continuously in the background, and that is what the 70ms measurements were. The bound is now a limit: the window grows because the reader moved, and never speculatively. `standUpSome`, `growing` and the frame loop that drove them are gone. **It moved in two-screen steps**, which is the boundary that could be felt. Crossing one moved the limit two screens at once and cut a chunk off the trailing edge in a single frame; coming back the other way needed all of it again, so oscillating around a boundary rebuilt the same rows repeatedly -- measured in the last report as twenty-two rows dropped and immediately wanted back, which is also where the flicker was coming from. Recomputed every time, the trailing edge retreats a row at a time and there is no boundary left. The step existed because this used to be a scan of every row; it has been a binary search since the last commit. **It was measured against the viewport as it is now**, so the IME animation shrank it on every one of its thirty frames -- trimming the far edge, disposing rows and recomposing the list, thirty times, for a keyboard. How much to keep alive is not a question the keyboard has any business changing: it is about how far the reader might scroll, and they can scroll just as far with it open. It is sized against the tallest the viewport has been. The bound also came down from eight screens to five. Eight was chosen when keeping a row alive was believed to be free; the report now says plainly that it is not -- three quarters of the draw phase is framework bookkeeping that grows with live nodes rather than with what is on screen. Measured on the emulator, eighty swipes oscillating across what used to be a boundary: measurements of the transcript went from 51 at 8.3ms mean and 70.3ms worst to 11 at 2.3ms mean and 4.3ms worst, and rows composed from 270 to 10. Three keyboard cycles leave the transcript at 0.36ms of the frame's draw phase. Three open/scroll/close cycles report nothing unbuilt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Languages
Rust
54%
Kotlin
43.6%
Shell
2.4%