[Direct-Launch]

Part of #482. MarkdownRenderer.svelte re-parsed the entire accumulated message (container.empty() + MarkdownRenderer.render) on every streamed token, forcing a full style/layout recalc per token that stalls the whole UI for the length of a reply (a DevTools trace showed 3,146 ms UpdateLayoutTree + layout thrashing, with the plugin the dominant cost).

Now coalesced to one render per requestAnimationFrame: the effect re-runs on each content change and its cleanup cancels the previous pending frame, so a burst of tokens collapses to one re-parse per frame (~60 Hz). Latest content always wins, so the final token is never dropped; the pending frame is cancelled on unmount.

Tested: real vault, reasoning model, long replies — stutter gone, final reply renders complete. bun run check clean.

AI assistance: developed with AI assistance (Claude) and tested in a real vault before submitting; disclosing per the contribution guide.

[greptile-apps]

Greptile Summary

The PR coalesces repeated streaming-markdown updates into one render per animation frame, reducing full-message reparsing and layout work while retaining lifecycle guards.

• Captures all render inputs synchronously so Svelte tracks changes to content, source path, and math settings.
• Cancels pending frames and prevents superseded or unmounted asynchronous work from mutating the container.
• The latest change fully addresses the prior enableMath reactivity finding.

Confidence Score: 5/5

The PR appears safe to merge; the previous math-setting reactivity issue is fully fixed and no new actionable failures remain.

enableMath is now read synchronously within the effect, so changes retrigger rendering, while cleanup cancels pending frames and guards asynchronous work against stale or unmounted DOM updates.

Important Files Changed

Filename	Overview
src/components/ui/MarkdownRenderer.svelte	Coalesces markdown rendering through requestAnimationFrame and synchronously captures enableMath, resolving the prior reactivity concern without introducing a new actionable issue.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  U[Reactive input changes] --> E[Svelte effect]
  E --> C[Capture current render inputs]
  C --> F[Schedule animation frame]
  U --> X[Effect cleanup]
  X --> D[Mark old render disposed]
  X --> K[Cancel pending old frame]
  F --> R[Render latest markdown]
  R --> G{Still mounted and current?}
  G -- Yes --> N[Normalize rendered links]
  G -- No --> A[Abort stale work]

Loading

_{Reviews (2): Last reviewed commit: "fix(chat): track enableMath in the rende..." | Re-trigger Greptile}

[Leo310]

LGTM — this is what the trace in #482 asks for, and the lifecycle handling is careful: every dependency is read synchronously in the effect (reactivity is intact after the enableMath fix), and the cleanup both cancels the pending frame and marks in-flight async work disposed, which extends the old unmount guard to supersession.

I checked the one thing that could regress — layout reads that assume the markdown is already in the DOM. The only such path is scroll-to-latest after a send, which measures the new user bubble's top after tick(). Its position depends only on the messages above it (already painted), and the last message carries min-h-[95%], so the scroll clamp can't bite while the bubble's content is one frame late. The other consumers use a ResizeObserver or are static.

Format, lint, bun run check, and the full unit suite pass locally on this branch (the GitHub CI run needs a maintainer approval to start, which we'll do).

Two non-blocking notes, mostly for our own follow-up:

• This is a mitigation rather than the full fix — each frame still re-parses the whole accumulated message, so a very long reply can still push a single frame past budget. Incremental/append-only rendering of the streaming message is the real answer to the first half of #482; we'll pick that up on our side after this lands.
• The global window.requestAnimationFrame is consistent with the rest of the repo, so no change needed here.