perf(vscode): coalesce task timeline performance optimization

[marius-kilocode]

The shared Kilo chat TaskTimeline is used across Agent Manager, sidebar chat, and editor conversations. During streamed responses it previously reacted to every appended bar by synchronously reading scrollWidth and writing scrollLeft inside Solid's reactive update chain.

That read/write pair can force layout before the browser has finished applying the current DOM updates. Bursts of incoming parts can repeat the work several times before one paint. It also pulled the viewport to the newest bar while someone was scrolling through earlier activity.

Durable behavior

• Coalesce appended-bar scrolling into one requestAnimationFrame callback after the current DOM updates settle.
• Follow incoming activity only while the viewport is within one bar of the right edge.
• Preserve manual scroll position while earlier activity is being inspected.
• Resume following automatically after returning to the right edge.
• Preserve tooltip placement, drag and wheel scrolling, bar sizing, labels, and accessibility.

Why this target

Agent Manager was used as the realistic high-concurrency benchmark because it can stream one foreground transcript while multiple background sessions remain active. The result applies to the shared timeline component on every Kilo chat surface.

The initial 40-second profile used three concurrent sessions. Each built and exercised an isolated dependency-free Node project with bash commands, reads, writes, edits, tests, and CLI execution. The pointer remained outside the timeline, and synthetic sessionUpdated flooding was not used.

Webview event	Count
partUpdated	412
messageCreated	198
sessionStatus	100
partsUpdated	62
sessionUpdated	50
permissionRequest / permissionResolved	18 / 18

The synchronous TaskTimeline auto-scroll effect was the leading identifiable application frame. The larger getBoundingClientRect cost was not attributed to timeline tooltips because no tooltip hover occurred during capture.

Controlled result

The before/after replay ran the same 36 specified tool operations across three concurrent sessions. Both runs settled to the same relevant active-transcript inventory: 23 tool wrappers, 13 collapsibles, 12 closed tools, 1 open tool, 27 timeline bars, and 2 markdown roots.

Rendering-event volume was 319 before and 296 after. The normalized column accounts for that difference using partUpdated, messageCreated, sessionStatus, sessionUpdated, and partsUpdated events.

Metric	Before	After	Raw change	Per-event change
TaskTimeline CPU self-time	20.320 ms	2.959 ms	-85.4%	-84.3%
Chromium script duration	572.925 ms	457.614 ms	-20.1%	-13.9%
Style recalculation	1231.066 ms	968.152 ms	-21.4%	-15.2%
Layout duration	141.659 ms	117.196 ms	-17.3%	-10.8%
Trace script group	3773.61 ms	2815.37 ms	-25.4%	-19.6%
Trace layout group	1365.87 ms	1081.03 ms	-20.9%	-14.7%
Trace paint group	1302.15 ms	1049.99 ms	-19.4%	-13.1%
Longest task	76.64 ms	55.52 ms	-27.6%	n/a

The code comments retain the causal explanation so future timeline changes preserve the animation-frame batching and right-edge pinning behavior.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (4 files)

• .changeset/calm-timeline-follow.md
• packages/kilo-vscode/tests/unit/timeline-sizes.test.ts
• packages/kilo-vscode/webview-ui/src/components/chat/TaskTimeline.tsx
• packages/kilo-vscode/webview-ui/src/utils/timeline/sizes.ts

lgtm — the animation-frame batching and right-edge pinning logic is correct. Key points verified:

• cancelAnimationFrame is called in onCleanup, so no animation frame leak on component teardown.
• The frame === undefined guard prevents duplicate rAF scheduling; the !follow early-return inside the callback correctly handles the case where the user scrolls away while a frame is already pending.
• pinned() arithmetic is correct and the boundary tests (inclusive <=) match the implementation precisely.
• follow starts as true — consistent with the pre-existing behavior of always scrolling to the end on mount.

---

_{Reviewed by claude-4.6-sonnet-20260217 · 247,849 tokens}

_{Review guidance: REVIEW.md from base branch main}