Repository navigation
fix(web): Thinking shimmer no longer looks choppy - #30640
hideoneric wants to merge 1 commit into
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The shared activity shimmer uses finer animation steps while retaining its duration, visibility pausing and accessibility safeguards. The change is presentation-only, with reported measurements showing a modest CPU increase. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
|
Note Written by Verified in a real dev environmentverified unchanged head ran main reproduced the coarse thinking shimmer. the pr applied the browser sampling skipped some animation steps. these counts establish the finer cadence on the real path, not a cpu or power measurement. a second real turn exercised motion preferences, offscreen pausing, and cancellation; cancellation displayed "stopped by user" and offered resume. Not verifiednative electron, ios, android, macos, windows, high refresh physical displays, and cpu/power impact. compacting and worktree setup also share these css utilities but were not triggered. other provider adapters were not exercised. the separately captured motion recording is 25 fps and cannot demonstrate every step of the nominal 27.3 updates per second. |


Problem
The highlight that slides across "Thinking" looks choppy. #18191 switched it from
lineartosteps(30)to save CPU, which means it only moves about 14 times a second, roughly 4px per jump on the "Thinking" label. On a high refresh display next to smooth scrolling and text, those jumps are easy to see.Change
live-activity-focusand its counter now usesteps(60)instead ofsteps(30). The highlight moves about 27 times a second in jumps half the size. It still has a fixed update rate on any display, so it keeps most of the saving from #18191. Pausing off screen and reduced motion work as before. The running tool label shine (live-tool-shine) stays atsteps(30), because it animatesbackground-position, which repaints, and doubling its steps would cost more.Scope and approval
A two-value CSS change that tunes an existing animation. It keeps the trade-off from #18191 and moves the step count to a point where the stepping is no longer visible.
Verification
Measured in Electron 44.10.1 (the desktop runtime) on Linux with niri, on a 2560x1440 display at 180 Hz. The test page contains only the real overlay CSS and markup. I cycled through the four modes in 4 rounds of 10 seconds each and read CPU time from
/procfor every Electron process and for the compositor. Medians, as % of one core:steps(30)(before)steps(60)(after)linear(before #18191)steps(60)costs about 0.4% more Electron CPU and about 1% more compositor CPU thansteps(30), and stays well belowlinear. Electron CPU readings were steady across rounds (2.4% to 2.9% forsteps(60)). Compositor readings were noisier (3.1% to 5.3%).Recording of both timings side by side, rendered at 60 fps with each frame's animation time set exactly, so the capture adds no jitter of its own:
Not checked: macOS and Windows, and 60 Hz displays. On a 60 Hz display both timings update at the same rate as above, so the relative cost should be similar.