|
|
|
TODO: This is just a skeleton. Needs better explanations, references, test-cases and results.
|
|
|
|
|
|
|
|
MathJax rendering overhead is almost entirely in element dimension lookups. The actual operation that incurs the expense is page reflow, which under MathJax is triggered for every lookup.
|
|
|
|
|
|
|
|
It is important to reduce rendering overhead because:
|
|
|
|
* total MathJax processing time would decrease
|
|
|
|
* browser responsiveness during processing could be improved
|
|
|
|
For historical
|
|
|
|
[[outdated Google site Wiki page]]
|
|
|
|
|
|
|
|
Browser responsiveness to non-MathJax tasks is set by the internal processUpdateTime option. In the current release it is 500ms. For the page to feel responsive this should be well under (ref. the instantaneous threshold of) 100ms - this would allow time for page repainting, and responding to user clicks, scrolling, etc.
|
|
|
|
|
|
|
|
But processUpdateTime is currently ineffective if the time to render a single equation exceeds it.
|
|
|
|
|
|
|
|
Are there ways to decrease rendering overhead and / or break up rendering into smaller blocks that could facilitate improved responsiveness?
|
|
|
|
|
|
|
|
1. Ideal case: no lookups
|
|
|
|
Ideally MathJax wouldn't have to perform any dimension lookups (or at least do them all up front, before any math is processed). In this case, MathJax would create a block of HTML and insert it into the page and that would be it for a single equation.
|
|
|
|
|
|
|
|
This may never be achievable, but it does suggest another idea - a low-quality rendering that could be used on slow platforms, and even as a first pass on faster platforms.
|
|
|
|
|
|
|
|
2. Low-quality option: separate renderers
|
|
|
|
Two separate renderers are provided, probably both within the HTML-CSS ouput jax.
|
|
|
|
The low-quality mode could be the preferred option for slow platforms.
|
|
|
|
If low-quality was chosen as a pre-processing placeholder then the standard quality rendering might be built in a hidden part of the document and then just replace the low-quality rendering.
|
|
|
|
|
|
|
|
3. Low-quality option: differential rendering (FIXME: nomenclature)
|
|
|
|
Low-quality mode is the first pass of the standard renderer.
|
|
|
|
If low-quality mode is desired (eg for a slow platform) then rendering stops after the first pass.
|
|
|
|
The second pass adjusts the output of the first pass (although this might still be done by copying to a hidden part of the document and then copying back).
|
|
|
|
|
|
|
|
This option might even work with math HTML generated on the server.
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
* neither of the low-quality option solutions facilitate improved responsiveness if the standard renderer will still be called. This would require breaking up the standard renderer so it can yield several times within the processing of a single equation.
|
|
|
|
* on IE8, even inserting a moderately complex block of HTML without any element dimension lookups can (for larger pages) significantly reduce browser responsiveness. Thus the low-quality mode would need to be as simple as possible.
|
|
|
|
* another low-quality option could be the use of common font-families. This would allow older non-IE browsers
|
|
|
|
to not have to fallback to images. |
|
|
\ No newline at end of file |
