Uhm… we will look into it.
However, think how much lantency you have when you actually use latex? (you have to compile everytime)
or when you use Overleaf?
I’ve also noticed severe slowdowns when editing a math heavy note and having the rendered version up side by side. I also thought the exact same thing, that the entire note was getting re-rendered on every keystroke (or something along those lines).
It’s actually not usable as it is now and I instead workaround it by editing a chunk of math and then flipping over to the rendered version to make sure that it looks correct, and then flipping back to just editing mode.
I’m not on the most powerful computer personally, it’s the 2015 12-inch MacBook. (1.1 GHz Intel Core M, 8 GB 1600 MHz DDR3, Obsidian version 0.6.7)
However, think how much lantency you have when you actually use latex? (you have to compile everytime) or when you use Overleaf?
There’s more to unpack here. Firstly, Obsidian is a markdown editor, so let’s stick to its peers like Typora and VSCode for comparison. Secondly, I’m talking about typing latency (time from keystroke to the letter appearing), which is virtually nonexistent even in the LaTeX tools you mentioned.
Talking about VSCode (or any other markdown editor, for that matter), I think they traded typing latency for rendering latency; the preview doesn’t update in real time, there’s a miniature lag. I think that’s a good tradeoff — typing latency doesn’t have any place in a text editor.
I tried your document and it’s doing pretty well. What computer do you have?
Maybe it’s a Mac-specific issue? Or we have different standards? I doubt my gear is an issue (16GM RAM, i7 2.2GhZ) — and if it is, it certainly shouldn’t.
And @Alex2357, glad (and not glad) I’m not the only one having this issue! I’m of the opinion that a text editor should run on anything that is operable by a mouse — unfortunately I have to do the same workaround as you. Personally I’d prefer to have a small rendering latency rather than wait for every keystroke to appear.
Thanks @WhiteNoise Just a guess, but it seems like the render method for the preview is maybe getting called on each update to the note buffer and debouncing this call could help.
Math blocks are only re-rendered when they are changed. If your file separates each block of text using 2 line breaks (1 empty line) then they should only be re-rendered when you actually modify the source block.
I’ve downloaded the provided file to do some performance testing. There seems to be 3 major sources of performance slowdowns. My PC is too fast to experience any of them, but luckily the built in debugger can impose a 4x or 6x CPU slowdown, which shows the issues clearly.
HTML sanitizer is a bit slow. I’ve added a patch for this one (should be in 0.7.6), but it’s mainly slow because it re-sanitizes the whole document on edit, where it should only be re-sanitizing the edited blocks.
The whole document having so many separate pieces of LaTeX causes significant layout strain on the rendering engine. This one I don’t have much to help, but we do have plans for small optimizations here and there that should cut down on the performance cost of this. First optimization will remove elements that are outside of view, and second optimization will “box” panes so having a crowded preview pane won’t impact another editor pane, for example.
I am seeing extremely poor performance (high typing latency) in MD files making “heavy” use of latex blocks. In my case, I would quantitatively say that increased latency is clearly noticeable with more than 25 latex blocks, it becomes very annoying at 25-50 latex blocks, and it becomes difficult to actually track the cursor in the edit window with > 75 latex blocks. In my case, most of the latex blocks are short, between 10 and 50 characters.
I read the following:
Normally, when you use proper headings and markdown blocks (generally anything separated by a completely empty line in between), the app can recognize each block, and only re-render unchanged blocks.
in this bug report:
as well as the rendering comments in this bug report.
I’m currently using a 4.2Ghz quad core i7, 2018 iMac with 64GB RAM. When I have a MD file with a substantial number latex (mathjax eqns) in it, the typing latency becomes enormous if a linked preview window is open.
I do have many markdown blocks and headings breaking up the file, but as the number of latex blocks build up in a file, the apparent latency in the editor window continually increases until editing is essentially impossible.
I am wondering about possible ways to mitigate this issue. Some examples that have already been mentioned:
only rendering changed MD blocks.
only rendering MD blocks that would render in the visible viewport of the preview window (always including the block currently being edited).
reducing the compilation frequency of the preview window.
Hi, I am also noticing noticeable typing lags on documents with heavy math. I am on a Dell XPS 13 from 2019.
Quoting a previous idea:
I also notice that the rendered equation is refreshed in real time, but only for display equations. For inline equations, you edit it the latex code that the rendered equation appears only when the cursos steps out of the inline latex block.
Could it make sense to do the same for display equations? Only render when the cursor goes out. Or at least add a timer so that the render refreshes only after certain intervals, like 1 second, or 2 seconds? That way it should not hinder typing lag. Just a thought.
The issue in this BR is solved. If you have problems with a note, make sure that you can reproduce them in the sandbox vault (or no no themes, no plugins, restart).
Also, see if you have very long block of text not separated with with 2 line breaks (1 empty line). It helps with rendering.
If it still happens, create a new bug report and attach a copy of the note.