Debounce mathjax rendering via cooldown instead

[iamllama]

If we want to debounce while typing, the correct fix would be to wait to render until 500 ms after the last render attempt, not 500 ms after the user stops typing
#3803 (comment)

Currently, mathjax renders 500ms after typing ends. This pr changes it such that it renders immediately, with a 500ms cooldown between each render, even while typing, which should shorten the feedback loop and make it appear more responsive

The only time i've ever noticed lag with mathjax was during the case that #3828 handles, so perhaps the existing deboucing really is too conservative

[dae]

Code looks good as always. @Arthur-Milchior, could you test this change and see how it affects the issue you were originally having?

[dae]

On second thought, since Arthur might be busy, I'll YOLO this one in for the next beta, with the proviso that it'll need to be reverted if it causes the original problem to come back.

[Arthur-Milchior]

I wonder whether you wanted to ask @rlanday, because they were the one who had an issue with last implementation.

Before giving my feedback, I must state that while it's not yet clear to me which of the two implementations is the best for my use case, both are very fine and quite quite better than what the state of affairs was in February. I am not asking for changes unless you expect that many other users would agree with me. I can certainly live with the current implementation.

When I'm typing many commands, the refresh time may trigger in the middle of the command. For example, while trying the code, I just had the mathjax view show an error because I wrote ^{- and mathjax tried to render the text before I had time to end my upperscript with -1}.
Actually, since at the time the error was displayed, the missing } and more text were typed, the error disappeared very quickly. Which makes it looks very strange to have the mathjax view alternating between the rendering of the beginning of what I want to type, and just plain text on yellow background. This is kind of flashy and call my attention in a way I don't exactly like.

With the previous version where it waits for me to stop typing, I feel like I've a better understanding of what is displayed. Either I typed something that compile, with every { closed with }, etc... or I already know that MathJax is not complete and that I expect the yellow error

[rlanday]

Thanks for the ping. It seems like there are two issues the original change was intended to help with:

• Objective performance issues when typing: typing a character causes MathJax to re-render, which freezes the renderer (I’m not sure how the MathJax popup is implemented but the Chromium renderer of course runs on a single thread and I suspect the MathJax popup waits for all the DOM updates to finish before returning control to the user in the popup or something). It’s unclear to me whether the specific issue here was that generating the MathJax, updating the DOM, etc. is consistently slow, or if there’s some edge case being hit where it’s way more slow than normal, or worse, the whole renderer gets caught in an infinite loop and the user has to force-quit Anki. I’ve seen the latter before, but not on the latest version of Anki; if this is the issue, then debouncing during typing could make this more likely, since it increases the number of render attempts.

• Subjective preferences about how often the MathJax preview should update: personally I like that I can immediately see if what I’m typing is valid MathJax or not (e.g. if I know the braces are unbalanced since I’m not finished typing, it makes me somewhat uncomfortable/confused to see a rendered result). If you just want to see the result when you’re done typing, you can type the expression in the \(...\) or \[...\]. But per @Arthur-Milchior’s feedback, I guess some people prefer the other behavior.

I have not yet personally tested the behavior with this new change.

Tangentially related side comment re: performance issues with the editor: the worst performance/UX I’ve seen on 25.07.2 is when pasting content from a website with a bunch of links in it because it seems that Anki tries to load all the links for some reason, which sometimes fails and then throws an error. In general, the solution to performance issues like this with the MathJax is to avoid blocking the Chromium renderer thread (which handles typing, selections, copy/paste, etc.) with slow operations, which could involve better splitting up the MathJax popup and the card editor (I’m not sure how it’s currently implemented) or using WebWorkers to run certain operations in background threads.