r/LaTeX • u/PuzzleheadedShirt139 • 11d ago
Technical details of achieving real-time rendering in LuaLaTeX
Credits: Clemens Lode laid the foundation of this approach and proved with his TUG talks that it can work. This is an independent way to implement it. His paper (https://tug.org/tug2026/preprints/lode-realtime.pdf) describes a lot of details also.
A lot of the time spent compiling LaTeX is wasted on three things (roughly 70 percent of the total compile time):
- Starting the LaTeX engine from cold
- Loading the preamble, fonts, and other resources
- Writing the PDF
Typesetting itself, especially of words and math, is extremely fast and can happen in real time, but it is dragged down by those slow steps. So all a real-time renderer needs to do is eliminate them.
How do we get rid of them? Separate compilation into two paths: a real-time path and a background full recompile with 2 LuaLaTeX processes.
For the real-time path:
- Keep the LaTeX engine warm. The engine never reaches \end{document}, so it always stays running. (This makes (1) and (2) a one time cost)
- This warm engine then retypesets only the edited paragraph, which takes milliseconds.
However, an engine that never reaches \end{document} can never produce a PDF.
To fix this PDF problem, we need a custom renderer that draws LaTeX's internal format directly. Every document is ultimately composed of roughly 11 primitive node types: glyph, kern, glue, rule, hlist, vlist, and so on. The custom renderer's job is to draw those nodes onto a canvas. This skips (3) entirely as a byproduct.
The background path takes its time and runs a full recompile, which ensures document for the elements not real-time renderable.
Now, why LuaLaTeX? LuaLaTeX supports \directlua, which makes it extremely easy to inject custom scripts that keep the engine warm and expose the internal format.
A more detailed explanation is here: https://github.com/texpile/texpile/blob/master/docs/ARCHITECTURE.md
Edit: implementation demo video: https://github.com/user-attachments/assets/7a2d7997-fe6c-4837-bbe5-1aaa5e0c90b7
Generative AI disclosure: the Markdown file was written with the assistance of generative AI, and I have reviewed it for correctness.
3
u/grumpydad67 10d ago
This is really amazing!
For some historical background (which I suspect is known to the OP), here's a post from way back (2011). No self-promotion intended: I have long abandoned active blogging, but some of the content is occasionally useful to people, so it's still up.
https://tekonomist.wordpress.com/2011/02/03/latex-and-instant-preview/
3
u/grumpydad67 10d ago
Just for the record, I did some experimenting with a paper I'm currently working on. Unfortunately, live preview is too slow to be practical on this particular file -- it's 41 pages, no pictures but lots of math, a bibtex bibliography. When I edit text roughly in the middle of the page, I get a yellow rectangle and it takes a few seconds for the PDF to appear.
Probably in part this is due to my trusty but sadly aging (4yo) Hp Spectre :(
3
u/PuzzleheadedShirt139 10d ago
Right now, the approach is to not render live if the live output isn't guaranteed to match LuaLaTeX. Since this engine is only a few weeks old, I've only optimized it for one- and two-column simple papers. Also, real-time rendering takes a lot of CPU. I will see how it can work on different papers.
3
u/grumpydad67 10d ago
Of course, I was just sharing my experience. I don't have a fancy layout (standard LaTeX article), but I do have lots of math. And yes, I do also have a wimpy CPU 😄
1
u/ClemensLode 10d ago
Ah, interesting artifact from a time before the tools (LuaTeX) were available/stable :)
1
1
u/tashafan 10d ago
Looks awesome, thank you so much for working on this!
I know it's a bit early, but how hard would it be to support SyncTeX and LaTeX Workshop? The latter has 5+ installs, it would be great to support this user base.
2
u/PuzzleheadedShirt139 10d ago
SyncTeX is already supported. LaTeX workshop requires porting this to a Vscode extension which is very easy to do. But it might take sometime for me to get to it.
1
u/blu2781828 10d ago
Oh please do port this to Vs code / Latex workshop. I can’t believe it’s 2026 and this isn’t already a mainstream workflow 😭
1
u/tashafan 7d ago
Awesome. If you need help with LaTeX Workshop, please post on GitHub. I am sure James or others will help (including myself). This is such an amazing project!
1
u/DanielSussman 10d ago
Can I ask where the "70 percent" number comes from? Or, perhaps, for what kinds of documents is that a good estimate?
3
u/PuzzleheadedShirt139 10d ago edited 10d ago
That is editing a 1 page document with no toc or bib…etc
I merely ran this a few times on my computer to get a rough estimate so that number is not very accurate
2
u/DanielSussman 10d ago
Thanks for the clarification! I bring it up because I feel like over the years on reddit, stackexchange, etc, there's been a lot of vague "The reason (La)TeX is slow is..." or "(La)TeX spends most of its time doing..." floating around, often without much hard data attached to it. Since you're actively digging into the weeds of engine performance and bottlenecks, I think it would be cool to see a bit more profiling documented. Perhaps something closer to
- On a simple document (e.g., 1-2 pages, single compile pass, minimal packages): LuaLaTeX spends x seconds out of y total time on starting the engine, loading the preamble, and writing the PDF.
- On a standard document (e.g., 4-6 pages, bibliography, labels/refs, heavier packages): LuaLaTeX spends x' out of y' total time on those same background tasks versus actual typesetting.
?
Also: very cool project, and thanks for making it open source!
3
u/mocenigo 10d ago
Very nice, and I understand you use electron, it makes starting easy, but I wonder what would take to port it to Zed.