Queueing manual typesets, change in version 2.5?

[Jan Marthedal Rasmussen]

I have noticed the following (apparent) change in version 2.5.

If I do a bunch of manual typesets, such as performing

for (var k = 0; k < scripts.length; k++)

    MathJax.Hub.Queue(['Process', MathJax.Hub, scripts[k]]);

each element will be typeset and displayed one after one, causing a lot of flickering and, it seems, reduced performance (jsfiddle#1). Prior to version 2.5, the underlying queueing/typesetting system seemed able to batch the incoming Process/Typeset requests and do the typesetting/displaying in chunks, similar to submitting an array of scripts to Process in one go (jsfiddle#2).

I have attempted to come up with a "work-around", which pushes elements to process onto a queue if a typeset process is already executing, and then sending an array of elements to Process when MathJax becomes idle (jsfiddle#3). It seems to work ok, but I did like it better when MathJax took care of it.

My question is: Was this change deliberate or perhaps a side-effect of some other change? Is there a better way of making 2.5 behave as earlier versions in this regard?

[Davide P. Cervone]

I have noticed the following (apparent) change in version 2.5.

If I do a bunch of manual typesets, such as performing

for (var k = 0; k < scripts.length; k++)

    MathJax.Hub.Queue(['Process', MathJax.Hub, scripts[k]]);

each element will be typeset and displayed one after one, causing a lot of flickering and, it seems, reduced performance (jsfiddle#1). Prior to version 2.5, the underlying queueing/typesetting system seemed able to batch the incoming Process/Typeset requests and do the typesetting/displaying in chunks, similar to submitting an array of scripts to Process in one go (jsfiddle#2).

Neither version 2.5 nor 2.4 combined the typeset actions, and always did them separately.  The difference is that v2.5 added a slight pause between the input and output processing so that the processing message would update, while 2.4 didn't include that.  That means that not only the processing message can display, but so can the mathematics.  So you are seeing the mathematics as it is processed in 2.5 whereas you didn't in 2.4.  That does mean that the page reflows between each equation, and that is causing the performance loss that you see.  In 2.4, MathJax did not give up the CPU between and so the browser didn't get to redraw the screen.

You can remove the delay by adding

<script type="text/x-mathjax-config">

MathJax.Hub.processSectionDelay = 0;

</script>

to your file just before the script that loads MathJax.js itself.

Note, however, that the equations are still being performed one at a time, and this is the least efficient mode of operation for MathJax.  Your queuing approach in your third fiddle is far more efficient.  For example, on my computer, the v2.4 fiddle ran in 7 seconds.  The v2.5 one with processSectionDelay set to 0 runs in 5 seconds, and your queued version runs in 2 seconds.  So you can see that your more sophisticated approach is far better.  This is because each MathJax.Hub.Typeset() call requires a page reflow, and if you make all your typeset calls separately, the page reflow is performed for each equation (regardless of whether a redraw occurs or not), but when you buffer your calls using the queue, you have fewer Typeset() calls, and so fewer page reflows. 

I hope that clarifies the situation.

Davide

[Jan Marthedal Rasmussen]

Thank you, Davide, for your quick response and the interesting details. The situation is indeed clearer now.

- Jan