Lagging when typing

[taooceros]

Describe the bug
I have experinced some lagging for typing when preview is open. This will not happen when open preview in browser. Though there are still laggness on the preview in browser, it is not affecting keystroke in vscode. So I doubt either rendering is slowing down vscode or we kindly block waiting the rendering.

It seems like my document is unreasonably slow as it only contains 5 pages of text.

To Reproduce
Steps to reproduce the behavior (Library test):

proposal.zip

Expected behavior
Everything should be async and early outdated event should be dropped.

Package/Software version:

VSCode version(Help -> About):

Version: 1.86.1 (user setup)
Commit: 31c37ee8f63491495ac49e43b8544550fbae4533
Date: 2024-02-07T09:08:20.941Z
Electron: 27.2.3
ElectronBuildId: 26495564
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.22635

typst-preview extension version: v0.10.7

[Enter-tainer]

Thanks for attached zip. I just download it and try to edit it randomly. But it seems to be pretty smooth at this moment.(or it is my computer being too powerful? I'm using mbp m2pro.). Can you reliably reproduce the "laggy" problem? You can tell us how to replicate it so we can debug the problem on our own computer.

I'd also like to confirm that do you mean typst-preview will make vscode itself laggy? I mean the latency between press a key on keyboard and letter appears on vscode editor panel. Or do you mean typst-preview itself doesn't update preview panel quickly after you edit the source code?

[Enter-tainer]

possibly related: #126

[taooceros]

Thanks for testing. I edited the document on my laptop which is not as performant as an mbp. It's in windows but I am not sure that should matter.

The lagging is that text doesn't appear immediately at vscode after typing the key, which is the annoying part. It's ok with the preview has a small delay for the text to appear but not in the editor parts. Theoretically the web view rendering shouldn't affect the editor typing?

I feel like it's different than #126 as it appears whenever I open preview. I have experienced #126 before and reopening the preview will fix it.

[taooceros]

I can reproduce it consistently. Typing too fast (well not so fast) will cause the text to appear in vscode editor laggy. Probably better computer might fix it, but I do feel like we shouldn't affect the editing latency.

[taooceros]

And preview in browser won't have this issue (there are still delay in the preview update but that's fine), so I believe it is something related to how we handle keystroke in vscode.

[Enter-tainer]

Thank you for detailed explanation. There are also people reporting this issue before occasionally. I will try to reproduce this. But I guess there is no much we can do for this specific problem. In vscode, the preview panel(a webview) and the editor panel live in the same process and the preview panel needs a lot of CPU/Memory resource. When the preview panel gets more, the editor gets less, especially when the computer is not very "high-end". As you said before, when previewing in browser, it becomes less laggy so i guess that's the problem. For now I'd suggest you use preview in browser for better experience

[taooceros]

I am curious do the preview panel has to lie within the same process or it is possible to create a new process to hold the webview?

[Enter-tainer]

I am curious do the preview panel has to lie within the same process or it is possible to create a new process to hold the webview?

yes. not possible. it's vscode's limitation

[taooceros]

I think the main issue is that the rendering of the svg is slow. When I type I see the cpu usage of chrome (open in browser) increases to 10% I am curious by any chance we could have an incremental svg renderer (don't know how hard it is but assume very hard?).

Interesting enough, firefox seems to perform better (though its cpu usage is higher). I guess it might be more parallel as my labtop doesn't have a high frequency.

[Enter-tainer]

I think the main issue is that the rendering of the svg is slow.

Maybe

by any chance we could have an incremental svg renderer

there is already one.

[Enter-tainer]

The rendering of svg is actually performed by the browser, and there is very few we can do about it. currently we only replace certain dom nodes incrementally.

[Myriad-Dreamin]

We cannot run a SVG renderer "offscreen". But, we can consider a canvas renderer for low-end PCs, which may be a better solution. For canvas renderer, we can do rendering in another thread, OffscreenCanvas. That solves problem generally.

[Isaskar]

I can confirm this as well, on my 2019 Intel Macbook Pro. Having Typst Preview open causes lag and slowdown in the code editing window. It's not massive, and no keystrokes are missed, but it's very noticable and makes this extension quite annoying to use. It seems to me as though the code window has to wait for the preview window to finish updating before the code window can update, rather than them updating asynchronously.

This probably isn't an issue as long as your computer is fast enough but for slower PCs it would be nice if they updated indepentently, as they do for example if you just use the typst LSP and set it to compile on save. (That's otherwise a worse experience in every way.)

[Enter-tainer]

I can confirm this as well, on my 2019 Intel Macbook Pro. Having Typst Preview open causes lag and slowdown in the code editing window. It's not massive, and no keystrokes are missed, but it's very noticable and makes this extension quite annoying to use. It seems to me as though the code window has to wait for the preview window to finish updating before the code window can update, rather than them updating asynchronously.

This probably isn't an issue as long as your computer is fast enough but for slower PCs it would be nice if they updated indepentently, as they do for example if you just use the typst LSP and set it to compile on save. (That's otherwise a worse experience in every way.)

Is it still laggy when you open the preview in a browser tab rather than in vscode? You may try typst-preview.browser in command palette

[Isaskar]

Is it still laggy when you open the preview in a browser tab rather than in vscode? You may try typst-preview.browser in command palette

I tried the browser preview and there's no lag when using that. It's a very noticable difference when compared to using the standard preview.

[taooceros]

Still Previewing browser is suboptimal (I wish we can render as canvas if possible, since this would align with how the webapp works). The focus won't shift directly, which means if I want to use the jump to source functionality I have to shift the focus manually. Don't know whether this is possible?

[Enter-tainer]

The problem is preview panel and vscode ui is in the same single thread. And both of them do a lot of work. If the single core performance is not good enough, both vscode and preview panel becomes less responsive.

There are techniques that can optimize this like offscreen canvas, webworkers, or gpu accerated renderers. But currently we don't know where the bottleneck is. So we didn't start optimization yet.

[taooceros]

From my perspective, the rendering seems to be the main bottleneck. I think your observation is pretty correct. My labtop that is lagging is i5 1340p, which might have a relatively worse single core performance.

Though, even with preview in browser, the preview is lagging, while vscode is pretty fluent. Also, the compilation time seems to be only couple milliseconds, so should not be the bottleneck (and that should be run in a different thread). I think svg is just slow to render especially when the cpu is not powerful.

Further, the webapp is fluent for its preview even with larger document, in which I would say allowing an option for rendering in canvas (even though without offscreen canvas) could help to achieve a similar experience with the webapp on low end device. For a preview experience, people probably don't need the high resolution rendering with svg.

Since typst does have a canvas rendering backend, I wonder how hard would it be for us to adapt that to the preview?