Skip to content

fix(web): Thinking shimmer no longer looks choppy - #30640

Open
hideoneric wants to merge 1 commit into
pingdotgg:mainfrom
hideoneric:fix/smoother-thinking-shimmer
Open

hideoneric wants to merge 1 commit into
pingdotgg:mainfrom
hideoneric:fix/smoother-thinking-shimmer

Conversation

@hideoneric

Copy link
Copy Markdown

Problem

The highlight that slides across "Thinking" looks choppy. #18191 switched it from linear to steps(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-focus and its counter now use steps(60) instead of steps(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 at steps(30), because it animates background-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 /proc for every Electron process and for the compositor. Medians, as % of one core:

Mode Electron total GPU process Renderer Compositor (niri)
Paused (baseline) 0% 0% 0% 2.6%
steps(30) (before) 2.2% 1.1% 0.8% 3.3%
steps(60) (after) 2.6% 1.4% 0.8% 4.3%
linear (before #18191) 7.6% 4.6% 1.6% 8.4%

steps(60) costs about 0.4% more Electron CPU and about 1% more compositor CPU than steps(30), and stays well below linear. Electron CPU readings were steady across rounds (2.4% to 2.9% for steps(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.

@github-actions github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:XS 0-9 changed lines (additions + deletions). labels Nov 4, 2026
@macroscopeapp

macroscopeapp Bot commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved at 2b76e17

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.

@coderabbitai

coderabbitai Bot commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

Explain Change →

No actionable comments were generated in the recent review.

Walkthrough

The live-activity-focus and live-activity-focus-counter animations now use 60 steps per 2.2-second cycle instead of 30.

Changes: Live activity animation cadence

Layer / File(s) Summary
Update animation step counts
apps/web/src/index.css
The live-activity-focus and live-activity-focus-counter animations each change from 30 to 60 steps per 2.2-second cycle.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Bug fix

Possibly related issues

  • pingdotgg/t3code#28113 — The issue discusses stepped shimmer as a mitigation for mobile redraws. This change updates the web shimmer cadence, not the mobile implementation.
  • pingdotgg/t3code#27325 — The issue concerns power use from work-row shimmer. This change modifies the related web animation cadence but does not establish an effect on power use.
  • pingdotgg/t3code#9661 — The issue tracks generated frames from work-row shimmers. This change modifies the cadence of two web live activity animations.

Suggested reviewers: t3dotgg

Merge Risk: Minimal · up to 2b76e

The animation cadence change is limited to the intended step-count adjustment and is ready to merge.

Pre-merge checks: Passed 4
Check name Status Explanation
Title check Passed The title names the main change: the Thinking shimmer animation (live-activity-focus) is changed from steps(30) to steps(60) to remove the visible choppiness. It follows the conventional commit format…
Description check Passed The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section states the choppy highlight and the cause (#18191 moved it to steps(30)…
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Title check

Explanation

The title names the main change: the Thinking shimmer animation (live-activity-focus) is changed from steps(30) to steps(60) to remove the visible choppiness. It follows the conventional commit format and is clear and specific. The changeset is a two-value CSS change in apps/web/src/index.css, which matches the title.

Full details: Description check

Explanation

The description follows the template. It has Problem, Change, Scope and approval, and Verification sections. The Problem section states the choppy highlight and the cause (#18191 moved it to steps(30)). The Change section names the affected animations and the trade-off. The Scope section explains why a prior issue is not needed. The Verification section gives measurements in Electron on Linux, a table of CPU readings, a recording reference, and a list of what was not checked. The description does not link a triaged issue or maintainer approval, and the Scope section argues for an exemption instead of citing one. The recording placeholder is an unfilled HTML comment, so the recording may be missing. Those gaps are minor against the rest of the template, so the check passes.

Finishing Touches
Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Recent review info
Run configuration
Commits

Reviewing files that changed from the base of the PR and between 3368dd7 and 2b76e17.

Files selected for processing: 1
  • apps/web/src/index.css

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

@maria-rcks

maria-rcks commented Nov 4, 2026 •

Copy link
Copy Markdown
Collaborator

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head 2b76e177922efc0cbc854b50de6d380542d475ac against github/main at 8b44f42b14c8e273156474a924ccf29680dd7857 on linux.

ran vp i and one background dev server at a time. used the repository's playwright dependency with /usr/bin/google-chrome. created the project and conversation through the web app, selected codex gpt-6.1-sol, and submitted the same reasoning prompt on both revisions. no mocks, replay provider, fixtures, or injected ui.

main reproduced the coarse thinking shimmer. the pr applied steps(60) to both live overlay layers while keeping the 2.2-second cycle. sampled computed transforms during actual provider turns:

main: steps(30), counter steps(30), running, 60 changes / 4.413s
pr:   steps(60), counter steps(60), running, 111 changes / 4.410s
reduced motion: animation none, overlay opacity 0
forced colors: animation none, overlay opacity 0
scroll off screen: paused; scroll back: running
real codex turn: completed after 1m 14s; response rendered; composer restored
blacksmith: vp run check:changed github/main passed format and affected typechecks

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.

main before: real codex thinking turn

pr after: same prompt and viewport with finer thinking shimmer

Not verified

native 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.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:XS 0-9 changed lines (additions + deletions). vouch:unvouched PR author is not yet trusted in the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants