Lagging when typing

Question

Lagging when typing

taooceros opened this issue 10 months ago · 21 comments

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

Answer 1 · 2024-02-12T11:50:08.000Z

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?

Answer 2 · 2024-02-12T11:51:52.000Z

possibly related: #126

Answer 3 · 2024-02-13T16:33:08.000Z

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.

Answer 4 · 2024-02-13T16:39:06.000Z

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.

Answer 5 · 2024-02-13T16:41:29.000Z

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.

Answer 6 · 2024-02-14T01:30:13.000Z

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

Answer 7 · 2024-02-14T21:07:26.000Z

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?

Answer 8 · 2024-02-15T01:09:08.000Z

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

Answer 9 · 2024-02-15T06:23:32.000Z

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.

Answer 10 · 2024-02-16T01:44:29.000Z

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.

Answer 11 · 2024-02-16T01:45:41.000Z

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.

Answer 12 · 2024-02-18T06:57:35.000Z

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.

Answer 13 · 2024-03-14T09:46:21.000Z

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.)

Answer 14 · 2024-03-14T10:10:44.000Z

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

Answer 15 · 2024-03-18T09:24:58.000Z

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.

Answer 16 · 2024-03-20T01:07:24.000Z

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?

Answer 17 · 2024-03-29T07:30:46.000Z

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.

Answer 18 · 2024-03-31T06:36:28.000Z

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?

Answer 19 · 2024-07-15T02:37:16.000Z

You can try this in typst-preview v0.11.15 or tinymist v0.11.15: Myriad-Dreamin/tinymist#412

Answer 20 · 2024-07-15T17:02:23.000Z

I take a try and it feels faster, though still experiencing some lagging.

Answer 21 · 2024-07-15T23:04:03.000Z

For a preview experience, people probably don't need the high resolution rendering with svg.

We also utilize SVG for some responsiveness, like invert the color filter of image when you hover on it. As well as for bidirectional jumping, which uses SVG's bounding box on each element.

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

its canvas backend is rendering document offscreen. It is the part of webapp, so is not open-sourced. But before optimizing, we still don't have a nice way to profile the bottleneck during typing.