You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MJ 2.5 is out and the demo page now points to it (it uses latest/).
It consistently gives [Math Processing Error] on about half the math — same formulas every time:
AMScd: $ \begin{CD} A @<<< B @>>> C\\ @. @| @AAA\\ @. D @= E \end{CD}$
We reverted back to 2.4 as well for now. The problem for us lies in using iframes to host the previews, but loading mathjax in the outer document. Due to some legacy issues we can't just switch to divs, though that would solve it. Good luck!
All errors I saw were from CHTML code new in 2.5. They go away if I disable Fast Preview (and don't choose Fast HTML as the renderer).
Fast Preview can be set off by default, see http://www.mathjax.org/mathjax-v2-5-now-available/
changed the title [-][Math Processing Error]s with MathJax 2.5[/-][+][Math Processing Error]s with MathJax 2.5 => can't typeset detached[/+]on Jun 4, 2015
@mull
Forgot to update here: MathJax folks replied to that bug explaining my use case was never supported.
I'm calling Typeset() on detached DOM nodes, which happened to work (but not guaranteed to be correct) with 2.4's outputs which may temporarily move such math into DOM and back, but doesn't with 2.5's CHTML renderer.
The conclusion is that I must attach my math somewhere inside the DOM before calling Typeset (and preferably avoid display: none, see mathjax/MathJax#1179 (comment)).
[Issue very specific to my project: once it's typeset I can give the element to CodeMirror but then I won't be able to optimize with MathJax's Rerender() and friends (which I don't yet, #15) because they're async and CodeMirror may attach/detach the element I gave from the DOM at any moment as lines are scrolled in/out of screen.]
I now tried the simplest possible fix, which is to markText immediately instead of after typesetting.
I hoped this will both ensure typesetting within the DOM and fix #41.
But the former doesn't work - if it's far enough outside the viewport, CodeMirror doesn't attach it to the DOM so it still breaks with 2.5.
(It would also complicate or prevent the optimization of calling Typeset() on lots of math at once.)
So I must have a separate typesetting area. (and for #41 I'll need a temporary non-widget markText)
Things rendered properly with 2.5 if Fast Preview was turned off, but it was still 4 times slower than 2.4 out of attached DOM rendering. CommonHTML rendering method in 2.6 was just as slow as HTML-CSS.
I implemented in-DOM rendering but now that I can run 2.5 and 2.6 I'm also seeing dramatic slowdown:
7.5sec with 2.4.0, 50sec with 2.5.3, 50sec with 2.6.0-beta.1.
That's with Chrome on linux, HTML-CSS and fast preview on (which is useless - math stays hidden until fully rendered). {"fast-preview": {disabled: true}} makes no measurable difference.
Surprisingly, CommonHTML gives no improvement either - also 51sec. SVG also 48sec.
BTW, out-of-DOM with 2.4 was slower: 15sec vs 7.5sec for in-DOM. So 2.4 with in-DOM is so far fastest.
Firefox with 2.6:
HTML-CSS (no preview) took 104sec, Common HTML 98sec, Fast HTML 70sec, SVG 71sec, even MathML took 54sec!
That's compared to 2.4: HTML-CSS 24sec, SVG 10sec, MathML 10sec.
It's so damn slow I'm seeing 1-2 formulas at a time getting replaced...
I'm queueing Typeset for each formula separately. That's known as bad for performance (it prevents mathjax from scheduling a lot of measurements into one reflow). Perhaps this 2.4->2.5 speed regression is limited to such usage?
But your jsFiddle only calls Typeset once on 1 formula.
And wasn't CommonHTML suppossed to do few to none measurements?
I'll try to dig deeper (and produce simpler tests, with permalinks per version/config; ideally jsperf?) and report on MathJax mailing list.
I'm perplexed how it's possible that a big regression went unnoticed; normally people experienced 2.5 and 2.6 as faster...
I implemented batched typesetting in 7e1851e:
collect many formulas under one div and call MathJax.Hub.Queue(["Typeset", ...]) once on this div.
Now MathJax 2.5 and 2.6 are as fast as 2.4 (and 2.6's Common HTML is faster than 2.4)!
This may explain how come there was a big 2.4->2.5 slowdown that went unnotticed: it only happens when you dynamically queue many Typeset calls, which is a rare use case (most people have MathJax process existing content once when it loads).
I'll try to create minimal cases and report to MathJax devs, but it'll take me time.
The original issue here is fixed, leaving it open until I:
make 2.6 fast in all cases (large edits still queue many small Typesets, need smarter batching heuristic)
report slowdown upstream.
EDIT: obsolete, upstream is on 4.y already.
Activity
cben commentedon Feb 5, 2015
confirmed that MJ
2.4-latestworks.cben commentedon Feb 5, 2015
menu -> Show math as -> Error message =>
Error: Cannot read property 'firstChild' of nullcben commentedon Feb 5, 2015
The obvious
processEnvironments: truedidn't help. (docs are quite clear it defaults to true anyway)cben commentedon Feb 5, 2015
Same error also accissible in console as
MathJax.Hub.lastError.message.In firefox it gives different error:
q is nullmull commentedon Mar 16, 2015
I'm having the same trouble in a different project. Did you ever solve this?
cben commentedon Mar 16, 2015
Not yet, I stayed on 2.4 so far. I'll try to attack it today.
16.03.2015 14:14 пользователь "Emil Ahlbäck" notifications@github.com
написал:
mull commentedon Mar 17, 2015
We reverted back to 2.4 as well for now. The problem for us lies in using iframes to host the previews, but loading mathjax in the outer document. Due to some legacy issues we can't just switch to divs, though that would solve it. Good luck!
cben commentedon May 4, 2015
Reported with minimal case at mathjax/MathJax#1185
All errors I saw were from CHTML code new in 2.5. They go away if I disable Fast Preview (and don't choose Fast HTML as the renderer).
Fast Preview can be set off by default, see http://www.mathjax.org/mathjax-v2-5-now-available/
[-][Math Processing Error]s with MathJax 2.5[/-][+][Math Processing Error]s with MathJax 2.5 => can't typeset detached[/+]cben commentedon Jun 4, 2015
@mull
Forgot to update here: MathJax folks replied to that bug explaining my use case was never supported.
I'm calling
Typeset()on detached DOM nodes, which happened to work (but not guaranteed to be correct) with 2.4's outputs which may temporarily move such math into DOM and back, but doesn't with 2.5's CHTML renderer.The conclusion is that I must attach my math somewhere inside the DOM before calling
Typeset(and preferably avoiddisplay: none, see mathjax/MathJax#1179 (comment)).[Issue very specific to my project: once it's typeset I can give the element to CodeMirror but then I won't be able to optimize with MathJax's
Rerender()and friends (which I don't yet, #15) because they're async and CodeMirror may attach/detach the element I gave from the DOM at any moment as lines are scrolled in/out of screen.]cben commentedon Aug 31, 2015
I now tried the simplest possible fix, which is to markText immediately instead of after typesetting.
I hoped this will both ensure typesetting within the DOM and fix #41.
But the former doesn't work - if it's far enough outside the viewport, CodeMirror doesn't attach it to the DOM so it still breaks with 2.5.
(It would also complicate or prevent the optimization of calling
Typeset()on lots of math at once.)So I must have a separate typesetting area. (and for #41 I'll need a temporary non-widget markText)
theyak commentedon Oct 7, 2015
For kicks I wrote a jsFiddle with this issue. We will have to stay with 2.4 for now.
With 2.4: http://jsfiddle.net/35L1pegp/
With 2.5: http://jsfiddle.net/35L1pegp/2/
Things rendered properly with 2.5 if Fast Preview was turned off, but it was still 4 times slower than 2.4 out of attached DOM rendering. CommonHTML rendering method in 2.6 was just as slow as HTML-CSS.
Add callback to renderAllMath(), show time all rendering took in demo.
Minimal solution to #33: typeset in a div under CodeMirror-wrap.
cben commentedon Oct 17, 2015
I implemented in-DOM rendering but now that I can run 2.5 and 2.6 I'm also seeing dramatic slowdown:
7.5sec with 2.4.0, 50sec with 2.5.3, 50sec with 2.6.0-beta.1.
That's with Chrome on linux, HTML-CSS and fast preview on (which is useless - math stays hidden until fully rendered).
{"fast-preview": {disabled: true}}makes no measurable difference.Surprisingly, CommonHTML gives no improvement either - also 51sec. SVG also 48sec.
BTW, out-of-DOM with 2.4 was slower: 15sec vs 7.5sec for in-DOM. So 2.4 with in-DOM is so far fastest.
Firefox with 2.6:
HTML-CSS (no preview) took 104sec, Common HTML 98sec, Fast HTML 70sec, SVG 71sec, even MathML took 54sec!
That's compared to 2.4: HTML-CSS 24sec, SVG 10sec, MathML 10sec.
It's so damn slow I'm seeing 1-2 formulas at a time getting replaced...
Typesetfor each formula separately. That's known as bad for performance (it prevents mathjax from scheduling a lot of measurements into one reflow). Perhaps this 2.4->2.5 speed regression is limited to such usage?But your jsFiddle only calls Typeset once on 1 formula.
And wasn't CommonHTML suppossed to do few to none measurements?
I'll try to dig deeper (and produce simpler tests, with permalinks per version/config; ideally jsperf?) and report on MathJax mailing list.
I'm perplexed how it's possible that a big regression went unnoticed; normally people experienced 2.5 and 2.6 as faster...
Oh, and I should try KaTeX.
cben commentedon Oct 27, 2015
I implemented batched typesetting in 7e1851e:
collect many formulas under one div and call
MathJax.Hub.Queue(["Typeset", ...])once on this div.Now MathJax 2.5 and 2.6 are as fast as 2.4 (and 2.6's Common HTML is faster than 2.4)!
This may explain how come there was a big 2.4->2.5 slowdown that went unnotticed: it only happens when you dynamically queue many Typeset calls, which is a rare use case (most people have MathJax process existing content once when it loads).
I'll try to create minimal cases and report to MathJax devs, but it'll take me time.
The original issue here is fixed, leaving it open until I:
report slowdown upstream.EDIT: obsolete, upstream is on 4.y already.
Rename typesetting div class to .CodeMirror-MathJax-typesetting
MJ 2.7.1 with new CM-MJ that supports MJ >2.4
MJ 2.7.1 with new CM-MJ that supports MJ >2.4
MJ 2.7.9 with new CM-MJ that supports MJ >2.4