12
$\begingroup$

It appears that the preview box for making a new post updates on every key press. For small posts this is very useful and makes the whole process very user friendly as it permits immediate feedback on one's LaTeX usage.

However, for very long posts which contain a lot of LaTeX this feature starts to slow down, become laggy, and sometimes even cause my browser (just the tab) to crash (I am using fully updated Chrome). I find that the crashes typically occur when typing quickly in a post of approximately this length.

I think there should be an optional feature to limit the frequency with which the preview box is re-rendered. For instance, one could set a preference like

  • If my post is longer than 200 words, update the preview every 10 keypresses, or 5 seconds after a change.

  • If my post is longer than 200 words, update the preview no more than once per second.

  • Only update the the preview upon a manual click of an "update preview" button.

I think these or similar optional preferences could drastically improve the ease of writing a very long post which contains a lot of LaTeX.

What are the community's thoughts and suggestions on this?

$\endgroup$
  • 1
    $\begingroup$ This is a known problem with MathJax on recent versions of Chrome. $\endgroup$ – Bill Dubuque Jul 8 '12 at 4:36
  • 3
    $\begingroup$ The previewer slowing the process down to a crawl is not limited to Chrome. I haven't been able to crash Firefox this way, though. But it was really getting on my nerves recently while typing this and this answer. IIRC Davide Cervone described a somewhat unofficial workaround as an answer to a related question. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 5:31
  • 1
    $\begingroup$ It's annoying but does that make it a bug? $\endgroup$ – Gigili Jul 8 '12 at 9:30
  • $\begingroup$ It is annoying after 200 words. When you exceed 500 (a ball park figure - I haven't counted) it is a bug. You can try and edit either one of those long answers, and see how well it goes. Of course, may be my dual core 2GHz laptop just doesn't have the power it takes? $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 11:54
  • 1
    $\begingroup$ @BillDubuque, I think the correct characterization is "This is a known problem with Chrome when using MathJax in MSE's previewer." :-) $\endgroup$ – Davide Cervone Jul 8 '12 at 12:35
  • $\begingroup$ @JyrkiLahtonen, I am unable to reproduce the problem by editing the two answers you suggest. I editing continually for three minutes, typing pretty much constantly, at various speeds, but everything worked perfectly. $\endgroup$ – Davide Cervone Jul 8 '12 at 12:37
  • $\begingroup$ @Davide: Thanks for trying it out. I will try it. I retried those two answers, and lo and behold, it was barely noticeable. It looks like the problem only occurred (or at least was much worse) when I was first creating the answer. Can you suggest anything that might cause that? The way I recall it there were several keystrokes in the buffer with new characters appearing to the edit window at a rate of one per over a second (a subjective figure). The annoying part was that correcting typos was a pain as processing the arrows keys to move the cursor around seemed to take a lot of time. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 13:13
  • $\begingroup$ @Davide:Ok. I tried it a bit longer. The problem reappeared actually relatively quickly. I only had to add about a hunderd characters before it became quite slow again. I didn't add any TeX-code, just plain text. This time I kept Windows Task Manager open while editing. Firefox was consuming 50 per cent of the cycles, i.e. one half of the dual kernel. After I stopped editing, it took may be half a minute before FF cycle consumption was back to normal. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 13:32
  • $\begingroup$ For comparison, when typing this comment with a little bit of extraneous $$\sum_{i=1}^\infty\frac{2\pi}{i^2+1}$$ TeXing, FF cycle consumption seems to hover between 4 and 16 per cent. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 13:39
  • $\begingroup$ Trying it one more time I went back to the same offending answer. This time FF cycle consumption immediate shot up to 50 per cent, and nothing much could be done. It looks like the recent browsing history may affect this. (FF memory consumption is now up to 280 megabytes, kinda high, but FF memory leaks are a known problem - or so I have heard). $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 13:45
  • $\begingroup$ Tried editing the other offending answer. This time with GreaseMonkey and your fix installed. Much, much better. I need to do more testing before I'm sold to this idea. After all, I had to restart FF, so its memory consumption (that I for some reason associate with slowdowns) is still not quite up to that high level. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 14:16
  • $\begingroup$ During the time that MathJax is doing the typesetting of the math, the browser will be trying to take up all the time it can (it is 100% computable); on a dual-processor system, you should see 50% CPU for the browser during that time. That is perfectly normal, and does not indicate a problem. After you stop typing, MathJax will take a few seconds to finish typesetting the long answer, which accounts for the half a minute delay before returning to normal. For the short answer, the processing finishes before the next keystroke, so the process is not CPU bound as with longer posts. $\endgroup$ – Davide Cervone Jul 8 '12 at 14:56
  • $\begingroup$ @JyrkiLahtonen, can you say more about what you mean by "became quite slow again"? As you type, are the keystrokes showing up in the editing box as you type them (not the preview, but where you are typing)? Or do they show up in clumps only after you pause typing? $\endgroup$ – Davide Cervone Jul 8 '12 at 14:58
  • $\begingroup$ When it was slow (before installing your fix), the letters usually appeared/were deleted one at a time. Sometimes in lumps, but usually one at a time. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 15:04
  • $\begingroup$ @Davide: Now (with your fix in place) the letters come in lumps. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 15:15
3
$\begingroup$

You may want to try out the Incremental Preview extension, which causes the preview to update only the paragraph you are editing rather than the complete answer. That may help with the problem you are having.

Having tracked this issue since it first appeared, it is more complicated than your posting suggests, and it is not clear that either of your first two suggestions (about timing of preview updates) would resolve the issue. Indeed, an earlier version of the previewer used a pause before updating, and that met with considerable complaint.

I have been unable to reproduce the issue (ever) with current versions of Chrome in Windows 7. From the reports of those who do experience the problem, I am convinced that it is a memory management issue within Chrome (or perhaps Windows itself), not a bug in MathJax, although it is certainly the case that the heavy load put on the browser by the use of MathJax in the preview is producing the conditions that trigger the bug. It may be possible to change MathJax or the preview code in some way to avoid the problem, but without a reliable way to reproduce it (and I haven't even reproduced it once), I would just be shooting in the dark.

You mention the preview "slowing the process down to a crawl", but I also have not experienced that. The way the current preview works is that the preview text is replaced at each keystroke, as you suggest, and MathJax is started, but the next keystroke should interrupt MathJax so that you don't have to wait for additional math to be typeset (past the expression currently being typeset). My experience is that that is pretty snappy. The length of the answer should not really be an issue with this, since it can be interrupted at any point. (Of course, how much of the math get typeset before the interruption is dependent on the length.) If that is not what is happening for you, can you describe in more detail exactly what is happening? Thanks.

My suggestion is to try out the extension I like to above. I asked for feedback from Chrome users about whether this helped, but so far haven't had any. Perhaps you could let me know if this approach helps.

You might also want to try installing the STIX fonts, or the MathJax fonts, in order to eliminate loading web-based fonts, which is one possible source of problems.

$\endgroup$
  • 1
    $\begingroup$ I am an avid Firefox user, and I have to say that when writing very long answers things may work fine, but when editing long posts then the refresh may drive me slightly further into madness, with each keystroke the compilation of the text begins anew and since many times the top part is the only visible part anyway it keeps refreshing over and over and over again, and it can be a bit annoying. $\endgroup$ – Asaf Karagila♦ Jul 8 '12 at 13:05
  • $\begingroup$ I share Asaf's problems. Scrolling the window up and down, when this was happening was near impossible. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 13:17
  • $\begingroup$ I just installed the STIX fonts and everything looks all wrong now. It looks like a totally different font than what was previously used. It is too think, hard to read, and some symbols look much more awkward. $\endgroup$ – nullUser Jul 8 '12 at 13:20
  • $\begingroup$ @AsafKaragila, yes, with each keystroke, the refresh begins anew. The question is does it interrupt the previous typesetting or not? If it does, then the length of the answer should now slow down the response to typesetting. Of course, with longer posts, that means that you may interrupt before all the math is typeset, so you get some typesetting, and then when you continue to type, it goes between partly typeset and not typeset. That can produce an annoying flicker. Is that what you are complaining about? What I'm trying to understand is the OP's "slows to a crawl" concern. $\endgroup$ – Davide Cervone Jul 8 '12 at 14:41
  • $\begingroup$ I am not experiencing "the crawl", I am annoyed by the constant refreshes (which eventually may slow down a bit the process, usually if the post is very long). If the refresh would occur only after a certain pause (1s) or (200) keystrokes things may become easier. $\endgroup$ – Asaf Karagila♦ Jul 8 '12 at 14:43
  • $\begingroup$ @JyrkiLahtonen, Scrolling while MathJax is processing a long answer can be sluggish. That is not a function of whether the math is typeset for each keystroke, but would be the case whenever the math is processed. If MathJax runs after a pause after you stop typing, scrolling will be slow during that time. $\endgroup$ – Davide Cervone Jul 8 '12 at 14:44
  • $\begingroup$ @Davide: Ok. It looks your Greasemonkey script helps a lot. For system speed comparison: the window (that presumably displays the processing time in milliseconds) gives me numbers between 2500 and 2800, when I open the edit window for one of those long answers. $\endgroup$ – Jyrki Lahtonen Jul 8 '12 at 14:48
  • $\begingroup$ @Asaf, having worked on several approaches to the preview code, I don't think your suggestion of only typesetting after a pause or certain number of keystrokes will help. MSE used to use a 1.5 second (I think) delay, and many complained that that was annoying. In any case, the whole message will have to be typeset sometime, and that is where you experience the slowdown. I still don't understand "which may eventually slow down the process"; because the refresh can be interrupted, how does that slow it down? Finally, can you explain how your suggestions will help? $\endgroup$ – Davide Cervone Jul 8 '12 at 14:50
  • $\begingroup$ @JyrkiLahtonen, will you let me know if the script helps with the Chrome crashes? $\endgroup$ – Davide Cervone Jul 8 '12 at 14:52
  • $\begingroup$ Davide, rapid loading of text may (I assume) cause a bit of strain for Firefox. This forces me to take slightly longer pauses between sentences and thus slows down the process. I must remind that this only occurs when editing, not when answering. My suggestion will be helpful because I will be less annoyed and thus focused better on finishing my thesis on time. :-) $\endgroup$ – Asaf Karagila♦ Jul 8 '12 at 14:59
  • $\begingroup$ The claim "this forces me to take slightly longer pauses..." is the one I object to. Because your next keystroke interrupts the process, this should not be the case. If you mean it takes longer to see the complete typeset result for longer messages, then yes, that is true, but your suggestions are going to make that worse, not better, since they will delay the typesetting even further. I'm not sure what distinction you are making between editing and answering, since both use the same process. Finally, I didn't mean how it would help you, but how it would prevent the effect you are seeing. $\endgroup$ – Davide Cervone Jul 8 '12 at 15:08
  • $\begingroup$ Perhaps we need to take this to chat? $\endgroup$ – Davide Cervone Jul 8 '12 at 15:08
  • $\begingroup$ When I said "it takes longer to see the complete typeset result for longer messages", note that that is because the message is long, not because the typesetting is occurring on each keystroke. That will be true no matter what method it used, and the one that causes typesetting to occur immediately on each keystroke is the one that minimizes that time. Any delayed typesetting approach will just make you wait longer at the ends of your sentences, frustrating you further. $\endgroup$ – Davide Cervone Jul 8 '12 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .