Understanding-mathjax-performance.md

@@ -88,12 +88,15 @@ MathJax essentially implements the Knuth-Plass algorithm, which goes bottom-up,
 
 This is the core problem: top-down vs bottom-up.
 
-However, SVG is often ~25% faster than HTML which is due to an additional problem with HTML layout. While the SVG output can reliably calculate relative sizes within an equation internally, HTML/CSS must ask the browser to determine these for it, requiring the browser to do a complete top-down layout before it can report the width and height of a subexpression.  This is a performance drain, as browsers are not designed to layout content repeatedly.
+However, SVG is often ~25% faster than HTML which is due to an additional problem with HTML layout. While the SVG output can reliably calculate relative sizes within an equation internally, browser limitations prevent the HTML/CSS output from determining these successfully.
 
 First, browsers do not reliably allow the calculation of width -- simply put, the sum of the width of characters is not the width of the string as it's laid out by the browser. To get around this, MathJax has to measure the substrings/subequations by laying them out and asking the browser to measure them. This problem naturally occurs recursively and shows dramatically in complex equations.
 
 Next, browsers do not provide javascript access to all font metrics (let alone modern features like OpenMath tables). That's why MathJax need to provide the metrics separately, which is the reason why MathJax only supports a handful of fonts. 
 
+
+To work around the width issues, MathJax recursively asks the browser to layout & measure subexpressions. This is a performance drain, as browsers are not designed to layout content repeatedly.
+
 While widths can be measured correctly as mentioned above, heights cannot be measured accurately since browsers provide only the font height/depth (the maximal height/depth of *any* character in the font). Since this is the same for every character in the font, MathJax has to compensate for these incorrect measurements itself.
 
 Preliminary tests have shown that deactivating these measurements will speed up the HTML output to the level of the SVG output. However, this will currently come at a loss of rendering quality (although the preliminary tests have shown that modern browsers do a much better job than those in place when MathJax was initially conceived). We can work with browser vendors to improve things on their end, e.g. the Chrome team seems interested in this; the necessary browser improvements could increase typesetting quality in browsers in general.
@@ -144,9 +147,9 @@ By tweaking the way content appears on the page, we could reduce the impression.
 
 * multi-pass layout
   * We can add a first "quick & dirty" rendering and then re-render until full TeX-quality is achieved.
-  * We can 
+  * We could provide tools for server-side pre-processing of SVG which gets replaced with MathJax rendering on the fly.
 * rendering small equations before large ones
-  * Due to the recursive nature of our output, complex equations take much longer. In combination with equation-chunking (the number of equations MathJax will reveal on a page at once), this can lead to negative perceived performance. For example, a page rarely starts with a highly complex equation but usually has a number of small inline equations before a complicated one shows up. However, the chunking prevents those small ones to show up until the large ones are typeset. A size-oriented chunking could reduce this problem.
+  * Due to the recursive nature of MathJax output, complex equations take much longer. In combination with equation-chunking (the number of equations MathJax will reveal on a page at once), this can lead to negative perceived performance. For example, a page rarely starts with a highly complex equation but usually has a number of small inline equations before a complicated one shows up. However, the chunking can prevent those small ones to show up until the large ones are typeset. A size-oriented chunking could reduce this problem.
 * local storage
   * Local storage could save rendered output and MathJax wouldn't have to re-typeset while a user browses back and forth.
 
@@ -166,7 +169,7 @@ The advantage would be that MathJax could help move browser vendors to enable be
 
 A very basic problem is that the Knuth-Plass bottom-up algorithm we use has to work against the top-down HTML/CSS layout algorithms. This problem cannot be resolved and affects performance.
 
-We could investigate a fundamentally new approach, letting the browser do the layout for us. The latest CSS modules such as flexbox could enable native rendering speed while offering much improved rendering.
+We could investigate a fundamentally new approach, letting the browser do the layout for us. The latest CSS modules such as flexbox could enable native rendering speed but are still in their infancy.
 
 #### Dropping support for legacy browsers