Desktop: scroll sampling forces repeated synchronous layout on long conversations

[xlpoistop-prog]

Desktop: scroll sampling forces repeated synchronous layout on long conversations

Environment

DSH desktop	0.2.0-rc.2
Chromium	152.0.7977.54
OS	Windows 11 Pro 25H2, build 26200
CPU	Intel i5-10400 (6C/12T)
GPU	AMD Radeon RX 6800 XT, driver 32.0.21045.5002
Display	2560x1440 @ 165 Hz
Session size at the time	20.4 MB on disk, 345 message rows, 15,927 DOM nodes

Symptom

In a long conversation, the window janks. It needs both of these at once:

• the assistant is streaming output, and
• the reader is scrolling

Either one alone is fine. When both happen, the system IME janks in step with
the window — so the composer becomes unresponsive at the same moments.

Cause

The scroll sampler. During a scroll it runs on a 500 ms timer, and each run reads
layout geometry several times in a row.

SCROLL_SAMPLE_INTERVAL_MS = 500

onScroll = (scroll) => {
  ...
  this.sampleTimer ??= window.setTimeout(this.flushSample, SCROLL_SAMPLE_INTERVAL_MS);
};

onScrollEnd = () => { this.flushSample(); };

flushSample calls readScroll(), which calls metrics(), which calls a free
function that reads three layout properties:

function scrollMetrics(element) {
  const height = element.clientHeight;                    // forced layout
  return {
    top: element.scrollTop,                               // forced layout
    height,
    floor: Math.max(0, element.scrollHeight - height)     // forced layout
  };
}

When the reader is not following the tail, flushSample then calls
capturePosition():

capturePosition() {
  const { list, scroller, composer } = this.elements;
  const viewport = scroller.getBoundingClientRect();                          // 1
  const bottom = composer?.getBoundingClientRect().top ?? viewport.bottom;    // 2
  let anchor = null;
  if (typeof document.elementsFromPoint === "function" && bottom > viewport.top) {
    const content = list.getBoundingClientRect();                            // 3
    const left = Math.max(viewport.left, content.left);
    const right = Math.min(viewport.right, content.right);
    for (const element of document.elementsFromPoint(...)) {                  // 4 hit test
      const row = element instanceof HTMLElement ? element.closest("[data-chat-anchor-key]") : null;
      ...
    }
  }
  if (anchor === null) {
    const rows = list.querySelectorAll(                                        // 5 full-list query,
      "[data-chat-flow-key]:not([data-chat-group-key])"                        //   4 x :not()
      + ":not([data-chat-flow-kind=\"turn-process\"]):not(:empty):..."
    );
    let low = 0, high = rows.length;
    while (low < high) {                                                       // 6 binary search
      const middle = low + high >>> 1;
      if (rows.item(middle).getBoundingClientRect().bottom > viewport.top)     //    forced layout
        high = middle;                                                         //    per iteration
      else low = middle + 1;
    }
    const row = rows[low];
    anchor = row !== void 0 && row.getBoundingClientRect().top < bottom ? row : rows[0] ?? null;
  }
  const key = anchor?.dataset.chatAnchorKey;
  return anchor === null || key === void 0 ? null : {
    anchorKey: key,
    anchorTop: anchor.getBoundingClientRect().top - viewport.top,              // 7
    scrollTop: scroller.scrollTop                                              // 8
  };
}

Eight or more layout reads per call, one inside a loop. On a document with
15,927 nodes and 156,483 px of scroll height in a 706 px viewport — 222 screens,
none of them virtualized — each read is expensive when layout is dirty.

Why the two triggers must combine

scenario	layout when the sampler reads it	result
scroll only	clean; reads hit cache	smooth
stream only	no scroll sampling runs	smooth
stream + scroll	dirty; just invalidated	jank

Evidence

1. Tracing

devtools.timeline + disabled-by-default-devtools.timeline.stack,
ReturnAsStream, 50 s of streaming plus scrolling: 1,755,733 events, 372.6 MB.
Renderer main thread, top events by total time:

event	calls	total ms	avg ms	max ms
RunTask	72,356	32,524	0.449	529.0
ProxyMain::BeginMainFrame	1,520	16,415	10.799	503.7
FunctionCall	36,496	12,389	0.339	526.1
Receive mojo message	6,865	9,229	1.344	528.9
Layout	1,608	8,017	4.986	288.7
V8.GC_MC_INCREMENTAL	30,681	3,805	0.124	3.8
UpdateLayoutTree	1,592	3,653	2.295	290.4
EventDispatch	2,022	1,809	0.894	419.7
Paint	7,093	1,171	0.165	2.9

Layout is 2.2x style recalculation and it is the single largest block. Frame
rate: 1,520 BeginMainFrame in 50 s = 30.4 fps.

Note for anyone else measuring this: Performance.getMetrics over
CDP reports LayoutDuration at roughly 4% here, which reads as negligible and
is wrong. The trace disagrees by more than an order of magnitude.

The longest tasks:

529.0 ms  Receive mojo message -> FunctionCall (client core) 526 ms -> Layout 289 ms -> UpdateLayoutTree 216 ms (12,286 elements)

503.7 ms  ProxyMain::BeginMainFrame -> Layout 235.8 ms -> Layout 232.1 ms -> UpdateLayoutTree 7 ms
          (468 ms of layout; style recalculation is not involved)

426.4 ms  EventDispatch compositionstart -> FunctionCall 215.8 ms -> UpdateLayoutTree 212.6 ms (12,257)
                                        -> FunctionCall 202.3 ms -> UpdateLayoutTree 200.1 ms (12,258)

2. Style recalculation is normally cheap

elementCount was present on all 1,592 UpdateLayoutTree events:

min 1 | median 5 | p90 9 | p99 168 | max 12,420 | mean 117.5

   1-5        27    1.7%
   5-20    1,517   95.3%
  20-100       9    0.6%
 100-500      25    1.6%
2000-inf      14    0.9%

Pearson correlation between elementCount and duration: r = 0.9933.

Retracted claim. I first believed that body[data-*]-prefixed selectors in
the skin system forced every recalculation to be document-wide. They do not.
95.3% of recalcs touch 5-20 elements. Only 14 in 50 s are document-wide, and
those cost 200-290 ms each — so they matter, but they are not the mechanism.

3. A/B on the live document

Each round inserted 60 real nodes into the message list, then immediately forced
layout — reproducing the sampler's situation rather than a synthetic one:

variant	forced layout avg	forced layout max
baseline	277.3 ms	329.6 ms
contain: layout paint style on rows	272.2 ms	331.6 ms
content-visibility: auto + contain-intrinsic-size on rows	22.0 ms	29.1 ms
both	27.8 ms	32.9 ms

Retracted claim. An earlier version of this test dirtied layout by writing an
attribute no stylesheet referenced, then measured 0.00 ms and concluded the
sampler was cheap. That attribute never invalidated layout, so the reads hit
cache. The numbers above use real node insertion.

4. The IME symptom is queueing, not IME cost

EventDispatch by type:

type	count	total ms	avg ms	max ms
scroll	284	663	2.334	5.5
compositionstart	2	424	211.9	419.7
scrollend	37	258	6.962	218.5
keydown	11	231	20.98	223.5
input	10	22	2.196	2.7
wheel	148	20	0.133	0.3

compositionstart fires twice, costs 424 ms, and its children add up to roughly
830 ms of main-thread work per keystroke. keydown averages 21 ms, 3.5x the
6.06 ms frame budget.

The IME is not the cost: the Weasel TSF service runs in the browser process and
consumes 0.031 cores. Chromium's IME path is a synchronous round trip — key to
browser process, browser to renderer, renderer back to browser with the caret
rect and surrounding text — and every leg crosses the busy renderer main thread.
So the IME is a queuer, and also a trigger.

Ruled out by measurement

hypothesis	measurement	verdict
GPU compute bound	3D engine 8-22%, idle 89% of the time	no
GPU rasterization / zero-copy / OOP raster	A/B: -2.2%	no effect
Vulkan backend	--use-angle=vulkan: 22.01 ms/frame vs 6.06 ms on D3D11	3.6x worse
Thread starvation	205 threads, 1 at >60%, 202 idle	serial, not starved
Cross-adapter composition	all processes on one LUID	no
Virtual display adapters	both report "no output"	no
Blur shader cost	static blurs +0.05 s; animated +0.26 s	not the driver
IME self-cost	0.031 cores	no
Unlocked vsync / frame rate	--disable-frame-rate-limit --disable-gpu-vsync: +232%	harmful
CSS rule count alone	4,873 rules, but 95.3% of recalcs touch 5-20 elements	not the driver

Two of these looked like wins at first and are worth recording as traps.
--use-angle=vulkan cut main-thread time by 79% — by rendering 72.5% fewer
frames at 3.6x the per-frame cost, which is worse for the user. And
--disable-frame-rate-limit made things substantially worse rather than better.
A main-thread duration without a matching frame count is not evidence.

Suggested fixes

In the sampler.

• Batch the reads: collect every rect first, then compute. Reads are currently
  interleaved with logic that could depend on them.
• Remove the per-iteration getBoundingClientRect() from the binary search.
  Either read the candidate rects once, or cache row offsets and invalidate on
  resize.
• Replace the querySelectorAll — in particular :not(:empty), which needs
  content evaluation rather than an attribute test — with a row list maintained
  by a MutationObserver, or with IntersectionObserver state.
• Take height from a ResizeObserver cache instead of reading clientHeight /
  scrollHeight on every sample.
• elementsFromPoint is a hit test: it needs layout and allocates a stack. An
  anchor key kept current in the scroll handler would avoid it.

In the message list.

content-visibility: auto on message rows is worth -92% on the forced layout in
the A/B above, and it is a one-property change. The caveat is
contain-intrinsic-size: with 345 rows over 156,483 px the average row is about
453 px, so a guessed value has to be in that range or the scrollbar will shift as
rows first render. The auto keyword makes the browser remember the last
rendered size, so it is only the first pass that can shift.

Longer term. Node count reached 15,927 with no windowing. A virtualized list
would address the unit cost rather than compensate for it.

Reproducing

"<install>/DeepSeek Harness.exe" --remote-debugging-port=9222

Then drive CDP from any Node 22+ (global WebSocket, no dependencies):

• Performance.getMetrics deltas on a timer
• Tracing.start with devtools.timeline and
  disabled-by-default-devtools.timeline.stack, transferMode: ReturnAsStream
• Debugger.getScriptSource on the largest scriptParsed target to read the
  client bundle's own source
• Performance.getMetrics is not enough on its own; see the note in Evidence 1

One counter gotcha: Get-Counter on Windows needs two samples for percentage
counters. A single call returns 0 and reads as "the GPU is idle".

[slyyr]

With a conversation containing hundreds of message rows and thousands of DOM nodes, synchronous layout during scroll can become expensive very quickly.

I’d first check whether the scroll handler is repeatedly reading layout information such as offsetHeight, clientHeight, getBoundingClientRect(), or scrollTop after writes to the DOM. A read-after-write pattern inside a high-frequency scroll callback can force the browser to perform layout synchronously.

A safer pattern is to batch scroll sampling with requestAnimationFrame() and avoid mixing DOM writes and layout reads in the same callback.

For example, conceptually:

scroll event
↓
store latest scroll position
↓
requestAnimationFrame
↓
perform one measurement
↓
update state

I’d also profile a long conversation with Chrome/Chromium Performance tools and look specifically for repeated Layout events originating from the scroll handler.

If virtualization is not already being used, that is another important consideration. Rendering thousands of message/tool DOM nodes at once makes every layout/paint operation more expensive.

A useful regression test would compare scroll performance for a 20-message conversation versus a 300+ message conversation and verify that layout work doesn’t grow unnecessarily with the total number of off-screen rows.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.