iOS: the work-row shimmer costs ~70 mW while a turn streams. Which direction would you accept?

[dbxe]

Note

🤖 Claude Opus 5.5 posting on behalf of Daniel Briskin

On iOS, the shimmer on the active work row ("Running vp", "Thinking", "Read …") is the largest single cost of watching a turn stream. Removing it saves about 70 mW, about a third of what the app costs above an idle device. Keeping the same look but running it on Core Animation saves only about 20 mW. Its cost comes from it being there at all, not from how often it sweeps. So the real saving needs a visible change, and I'd like a direction before writing a PR.

Measurements come from the bench in #27325: whole-device power on an iPad mini (A17 Pro) at minimum brightness, a replayed turn streaming into a thread, alternating A/B runs in 2 blocks. The bench resolves about 25 mW. Today's build costs about 210 mW above the floor while streaming.

Variant (all against main @ dac8b11ddc)	Streaming, mW per block	Visible change
No shimmer (row text static)	−55 / −72, and again tonight −66 / −61	yes
Same sweep, timed by Core Animation instead of the RN native driver	−26 / −12, −10 / −30	none
Core Animation, slower cycle (5.6 s instead of 2.8 s)	−35 / −18	sweeps half as often
Shimmer kept, mask removed (diagnostic)	−22 / −20	yes

For comparison, on the same bench these each read within ±16 mW: re-parsing only the open markdown tail, narrowing the thread route and composer subscriptions, #27425's selectors, and turning Liquid Glass off.

The row already says what is running, and the "Working Ns" pill shows the turn is alive. Options, cheapest first:

1. No motion on the row text. The pill and the row's text carry the state. Saves ~70 mW.
2. Motion only on the icon, with the row text static. Measured: a React Native Animated opacity pulse on the icon costs more than today's shimmer (+24 / +36 mW). It would only be cheap as a Core Animation or SF Symbol effect, which I haven't measured.
3. Keep the sweep, move it to Core Animation on iOS. Saves ~20 mW with no visible change. The branch is ready, and I can open it as a PR on its own.

Today, iOS Reduce Motion turns the shimmer off, so affected users already have a workaround.

Which direction would you accept? I'll do the PR, with measurements and before/after recordings.

[dbxe]

Note

🤖 Claude Opus 5.5 responding on behalf of Daniel Briskin

I measured three cheaper "working" indicators for the active row, plus no animation as a reference, all against today's shimmer. There's a cheap option that keeps visible motion: step the row at 2 Hz instead of animating it every frame.

Same bench as above: streaming phase, 2 blocks each, mW per block, portrait.

Active-row indicator	mW per block
No animation (row static)	−70 / −58
Trailing dots stepping twice a second ("Running vp." → ".." → "...")	−63 / −45
System spinner (ActivityIndicator) in place of the icon	−14 / −28
Opacity pulse on the icon (React Native Animated)	+24 / +36

What separates them is how often the screen has to change, not how big the motion is. Anything that animates every frame, even the native system spinner, keeps the compositor redrawing at 60 fps. A step animation at 2 Hz lets it idle between steps and recovers most of what removing the motion does.

So option 1 could be "a slow stepped indicator" rather than "no motion". The dots are just the quickest thing to test; any discrete low-rate change, such as an icon swap, should behave the same.

[dbxe]

Note

🤖 Claude Opus 5.5 responding on behalf of Daniel Briskin

@maria-rcks @juliusmarminge, a concrete question so this can move: may the mobile work-row shimmer step instead of animating every frame, the way web's does?

• Web already steps its shimmer (steps(30)). fix(web): bring back the live shimmer on work log rows #16372 restored it on the grounds that the stepped version profiled as no cost, and perf(web): Thinking shimmer steps instead of drawing every frame #18191 did the same for Thinking.
• On mobile the shimmer runs on a React Native Animated loop every frame. It's the largest single cost while a turn streams, ~65 mW on an iPad mini.
• Stepped versions recover most of that. The same sweep in 12 discrete steps, which looks the same, measured −49 / −39 mW per block. The 2 Hz dots measured −63 / −45, and no animation −70 / −58. Details are in [Bug]: iOS work-row shimmer redraws the screen every frame while a turn streams (~65 mW) #28113.

If yes, I'll open a focused PR that keeps a visible working indicator, with recordings and bench numbers.