A speedometer left of the usage chart, because it is the same kind of
thing about the app that the chart is about the conversation. It copies
rather than opens: a screenful of timings read on the phone is a
screenful nobody can act on, and what it produces is a message to
whoever is looking at the code.
It carries both halves of the question, because "the scroll is laggy"
has two causes and one appearance. From the platform, each frame's cost
split into its phases -- if measuring and drawing are small and the
total is large, the time is going into rasterising and no amount of
doing less work per row will move it. From the app, counts and timings
of the work the transcript actually does: rows composed, replies parsed
on the composing thread rather than ahead of it, runs grouped.
Counts rather than frame times are the point of the second half. This
emulator scrolls at the same 21ms median as the stock Settings app, so
every app-level cost here is under the floor of what it can measure and
no number taken in it says anything about a 120Hz phone. How many times
a row was composed is the same number on any machine, and it is the one
that says whether the work follows what is on screen or everything ever
loaded.
Pressing it empties both, so two presses measure two separate stretches
of scrolling rather than one and then the same one again.
The first reading from the emulator already says something: measure and
layout are 0.0ms at the median, so nothing is being re-measured, and the
cost is 3.9ms of recording the draw against 10.9ms of GPU. It also shows
60 loaded rows composing 177 times across three page loads -- every row
recomposing whenever a page lands -- which is the next thing to look at
if the phone says the work is ours.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
irisandClaude Opus 5
3e653c4797