live preview

[nyabla]

implements a live preview pane for the vscode extension.

Tasks:

• Generate PNGs server-side
• Respond to client command execute request with generated PNGs (base64 encoded data url)
• Show a preview pane (bare bones)
• Show the PNGs in the preview pane
• Update the preview on edit

You can help out by submitting a PR against the live-preview branch of my fork :)

[Bramas]

Hi, thanks for bootstrapping this.
I started working (playing) on the preview panel. You can see my branch https://github.com/bramas/typst-lsp/tree/live-preview.
Basically, I tried to use what is already done by the LSP when a file is changed, so that the LSP send the png to the client after compilation (so the compilation does not occur two times). Then the client put the png in a canvas.
I realized that creating the png is quiet long (>2seconds) so I just send the raw pixel data but still, it takes around 1 second, which is off course unacceptable :)

I think the best solution is to send the pdf (it is faster to generate and lighter) (I just experimented with that and it should take less than 300ms to be generated and received on the client. Then I think we should use something like pdf.js to show it in the preview panel.

on my branch, the command is "showPreview" and then when the document is edited it takes one second to preview

[Bramas]

I pushed a new version on my branch where the server sends the pdf in base64 and the client draws it in a canvas in the webpanel using pdf.js
it is pretty efficient already without any optimizations. One important optimization should be not to draw all the pages but only the ones that are modified (and maybe starting from the one that is currently visible in the panel)
Next we could think about not sending all the pages from the server to the client.

[nyabla]

@Bramas thank you for your feedback and your implementation!! :^)

[Bramas]

I just pushed a new version to my branch, where only the pages that have been modified are updated in the canvas. Now I think it's working pretty well! It will be hard to be faster.

I think the only way we can be faster is to just incorporate the typst compiler in wasm in the webcomponent itself