Skip to content

Fix visible artefacts when resizing the annot window (Windows)#83

Open
nikhilkrishna wants to merge 5 commits into
denolehov:mainfrom
nikhilkrishna:ui_performance
Open

Fix visible artefacts when resizing the annot window (Windows)#83
nikhilkrishna wants to merge 5 commits into
denolehov:mainfrom
nikhilkrishna:ui_performance

Conversation

@nikhilkrishna

@nikhilkrishna nikhilkrishna commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Problem

On the Windows build, resizing the window showed visible artefacts: a white flash on open, and — most noticeably on large files — content (text, syntax highlighting, and the bottom status bar) that visibly trailed the window edge during a drag, failing to repaint fast enough to keep up.

Fix

  • Windows webview background_color matching the theme's --bg-main, so WebView2 paints a solid themed background immediately instead of white. Gated to #[cfg(windows)] — macOS ignores the API and Linux never had the flash.
  • Grow-only content freeze: while the window is growing, a .resizing class applies content-visibility: hidden to the content tree (~7× cheaper per frame, measured), freezing the last-painted frame; the newly-exposed area shows clean themed space and content snaps back ~120ms after the drag settles. Shrinking stays live — it has no trailing edge, and freezing a fast shrink flashed blank.
  • Removed the status bar's backdrop-filter — its background is opaque, so the blur had zero visual effect but cost a full-width blur pass every frame.
  • Minor: content-visibility: auto + accurate contain-intrinsic-size: 22px on line rows for smooth off-screen skipping.
  • Feat: show toast when copying @ file reference

(WebView2), found while chasing content that visibly trails the resize:

1. Set background_color on every window builder to match the theme's
   --bg-main (light #fafaf9 / dark #1d1b16, System→light). WebView2 was
   painting its default white on window-open and at newly-exposed edges
   during resize; this paints a solid themed background on both the
   window and webview layers immediately. Regression test added.

2. content-visibility: auto on div.line so off-screen lines are skipped
   during layout. On a 10k-line file a resize re-wrapped every line
   every
   frame; forced-layout median dropped from 129ms to 27ms (4.7x), p95
   178ms→31ms, max 303ms→33ms (measured via CDP in-document A/B).
   Content
   and the bottom status bar no longer trail the resize as severely.
On a 10k-line file (~112k DOM nodes) the per-frame style+layout walk
can't keep up with a window resize, so content visibly trailed the
dragged edge. Measured the cost breakdown via CDP: style-recalc, not
layout, dominates, and it's proportional to node count — no pure-CSS
reflow tuning closes the gap.

Fix: while the window is GROWING, add a `.resizing` class that sets
content-visibility: hidden on the content tree (~7x cheaper per frame,
measured), freezing the last-painted frame; the outer scroller keeps a
themed background so the newly-exposed area shows clean empty space, and
content snaps back ~120ms after the drag settles. Grow-only on purpose:
shrinking has no trailing edge, and freezing a fast shrink outran the
browser's cached paint and flashed blank.

Also drop the status bar's backdrop-filter: its background is opaque, so
the blur had zero visual effect but cost a full-width blur pass every
resize frame. And fix div.line contain-intrinsic-size to the real 22px
line-height so off-screen height estimates are accurate.

Small/medium files were already smooth and stay so.
Replace the manual globalThis addEventListener/removeEventListener +
onDestroy plumbing with the <svelte:window onresize> binding Svelte
already provides. Behavior-identical (same debounced handler, same
reactive .resizing class), -8 lines, and Svelte owns listener teardown.
The background_color fix targets WebView2's white flash, a Windows-only
symptom. macOS ignores background_color (Tauri no-op) and
Linux/WebKitGTK
never flashed, so scope it to #[cfg(windows)] at all four window
builders,
matching the existing per-OS builder rebinds. The config helper and its
test are gated too, so non-Windows builds compile clean with no dead
code.
FileRefChip's copy-to-clipboard action was silent (TODO left in place).
Wires a bubbling `file-ref-copied` CustomEvent from the nodeview through
AnnotationEditor's existing listener pattern (mirrors excalidraw-edit)
and
threads an onFileRefCopied callback through AnnotationSlot/SessionEditor
to +page.svelte's toast, following the onImagePasteBlocked precedent.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant