Input delay when editing large/complicated documents with preview active

[IllustratedMan-code]

Describe the bug Documents that are large and or have lots of moving parts slow down the editor when the previewer is active. There is a noticeable delay between pressing a key and seeing the resulting character on screen. Note that this is the editor window that has higher input latency.

Expected Behavior

I'd expect the preview window to slow down as the document becomes more complex (more processing is done), but input latency should still be the same for the editor window.

Package/Software version:

VSCode version(Help -> About):

Version: 1.94.2 (user setup)
Commit: 384ff7382de624fb94dbaf6da11977bba1ecd427
Date: 2024-10-09T16:08:44.566Z
Electron: 30.5.1
ElectronBuildId: 10262041
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

Tinymist extension version: v0.11.32. I'm using the bundled tinymist.

Additional context I managed to reproduce the bug with the following example:

#import "@preview/wordometer:0.1.2": word-count, total-words
#show: word-count
#let total = [
  #set align(center)
  #box(stroke: black, inset: 5pt, radius: 5pt, [Word Count = #total-words])]


#lorem(500) 

// type something here to see delay
The quick brown fox jumpst over the lazy dog
#total

Make sure the preview is active and you should see input delay. If not, try increasing the argument to the #lorem() function.

Note that it isn't the wordometer package causing this exactly, but the processing required to count the words seems to slow down the editor. I've also noticed this occurring without the wordometer package.

I imagine updating the preview is a "blocking" operation for some reason, preventing the vscode window from updating until the preview does.

[Myriad-Dreamin]

previous issue: https://github.com/Enter-tainer/typst-preview/issues/245

[jannewer]

I am experiencing the same issue, both when using the Live Preview feature of VSCode and when using the built-in Simple Browser. However, opening the preview page with the Browser Lite plugin seems to fix the issue.

[ajyoon]

I'm encountering this issue as well in tinymist 0.13.14 on VS Code. Given that the problem appears to be related to the preview and editor UI sharing a single thread, would it be possible to have some workaround that adds some configurable preview render debounce? I would much prefer a 1 second delay in preview rendering over the current situation. I can confirm that the web preview with the "Eject preview panel" button workaround does work pretty well though.