1162409 - MathML rendering/layout is slow (compared with mathml.css)

Status: UNCONFIRMED

(Core :: MathML, defect)

Description

[Duan Yao]

Attachment: mathml-performance.xhtml

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150430030201

Steps to reproduce:

Toggle "hidden" attribute of a html block repeatedly (in a requestAnimationFrame loop), which contains tens of  MathML formulas, and measure the FPS. See the attachment "mathml-performance.xhtml".

As a reference, do the same thing in the attachment "fake-mathml-performance.xhtml", which use "fake" MathML instead -- that is, MathML elements without MathML namespace, and are  rendered with mathml.css (https://github.com/fred-wang/mathml.css).



Actual results:

Real MathML rendering is about 16~20 FPS (FF 37) or 27~29 FPS (FF 40a1) on my Core i5 2.0GHz machine.
Fake MathML rendering is much faster, about 45~52 FPS (FF 37) or 58~60 FPS (FF 40a1).

Google Chrome 42 has similar performance for fake MathML.



Expected results:

Firefox should render real MathML as fast or even faster than rendering fake MathML with CSS. Why there is such a big performance gap?

One of my application has a menu contains a list of MathML formulas, and due to the performance of MathML rendering, the menu feels not quite responsive when showing/hiding. I hope this can be improved.

Comment 1

[Duan Yao]

Attachment: fake-mathml-performance.xhtml

Comment 2

[Raniere Silva]

Attachment: screenshot of native vs css rendering of MathML

Duan Yao, thanks very much for your report.

> Firefox should render real MathML as fast or even faster than rendering fake MathML with CSS. Why there is such a big performance gap?

mathml.css isn't a replace for native MathML support. It only tries to improve readability at browsers without MathML native support (e.g. Chrome) for very simple equations (e.g. with powers) but have bad results with complex equations (see the attachment).

Native MathML is slower than CSS because it is much more complex. Instead of just change element position and size it have many complex rules.

I would vote to close this as not a bug but I'm not a expert.

Comment 3

[Duan Yao]

Hi, Raniere Silva,

I got your point. But I would argure that the formulas in my test cases are all relatively simple, and mathml.css can generate reasonable rendering result. I think ideally, native MathML rendering for simple formulas should not be much slower than CSS.

Of cause, the gecko layout engine may have a very different view of whether those formulas are "simple". But is there no room to improve native MathML rendering performance? It seems FF 40 has already been improved a lot.

Comment 4

[Raniere Silva]

> But is there no room to improve native MathML rendering performance?

Probably we can improve performance but there are very few people working on MathML support and since there are many things from MathML specification that need to be cover by Gecko I can say that improve performance isn't a high priority right now.

> It seems FF 40 has already been improved a lot.

There was a regression in MathML performance in the past but I believe this wasn't the case here.

We will have a IRC meeting next week and you are welcome to join. Details at https://etherpad.mozilla.org/mathml-2015-05.

Comment 5

[Frédéric Wang (:fredw)]

The main perf issue in MathML is bug 1009582. I hope that this could be eventually be fixed when we drop support for old math fonts and cleanup the nsMathMLChar code any further.

What do you get if you replace all the <mo> elements with <mn> elements?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> What do you get if you replace all the <mo> elements with <mn> elements?

It's about a 2x speedup for me.  That still leaves it about 2x slower than the css version.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So a profile shows us spending a lot of time computing intrinsic sizes  Part of that is bug 1009582, but also while MathML container frames do cache their intrinsic width, they don't use that cached value when computing intrinsic widths from the parent: the parent calls GetIntrinsicISizeMetrics directly.

So if we have a 4-deep nesting of container frames, we'll call GetMinISize() on the outermost one.  This walks all the way down the tree calling GetIntrinsicISizeMetrics and computes and caches the width for the outermost container.  When we reflow this outermost container, we go to GetMinISize() on its child, which once again walks down to the leaves.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: This speeds up things by 20-30% for me, though I don't know whether this patch is even close to correct

Comment 9

[Frédéric Wang (:fredw)]

cc'ing roc, as he has worked on bug 1139709