Last Comment Bug 744783 - Improve handling of attribute/child changes of MathML frames
: Improve handling of attribute/child changes of MathML frames
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: All All
: P5 normal with 1 vote (vote)
: mozilla29
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 477915 522393 656391 657279 dynamic-maction-math 745535 748779 755541 832713 832800
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-12 08:02 PDT by Frédéric Wang (:fredw)
Modified: 2014-03-21 06:45 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Frédéric Wang (:fredw) 2012-04-12 08:02:01 PDT
This is a bug for issues related to attribute/child changes of MathML frames. I make it depends on a couple of other bugs already reported. Andrii Zui has shown interest in working on these issues this summer. I also suggested him to write a couple of tests for dynamic changes in MathML expressions because I suspect there are other bugs currently unknown. Possible related issues to consider are attribute changes on an mstyle element, change of the selected child in maction@toggle, propagations of PresentationData / EmbellishData.

First there are two XXXldb comments in functions handling child changes

http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLContainerFrame.cpp#745
http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLContainerFrame.cpp#789

saying that we don't need to add dirty flags to all the descendants, just marking the ancestor dirty is enough. I'm also wondering why we do that. If that turns out to be unnecessary then we can just remove these operations.

There is also another XXXldb in nsMathMLContainerFrame::AttributeChanged:

http://mxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLContainerFrame.cpp#835

This function is sometimes overridden in child classes but I expect we can do a much better job here. Currently, it seems that we essentially almost always reflow the frame when an attribute changes.
Comment 1 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-04-12 20:39:33 PDT
Performance of dynamic changes to MathML DOMs shouldn't matter in practice, should it? Let's not spend energy or code on issues that don't matter.

(In reply to Frédéric Wang from comment #0)
> http://mxr.mozilla.org/mozilla-central/source/layout/mathml/
> nsMathMLContainerFrame.cpp#745
> http://mxr.mozilla.org/mozilla-central/source/layout/mathml/
> nsMathMLContainerFrame.cpp#789
> 
> saying that we don't need to add dirty flags to all the descendants, just
> marking the ancestor dirty is enough. I'm also wondering why we do that. If
> that turns out to be unnecessary then we can just remove these operations.

It is unnecessary. Just remove them.
Comment 2 Frédéric Wang (:fredw) 2012-04-12 22:41:06 PDT
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #1)
> Performance of dynamic changes to MathML DOMs shouldn't matter in practice,
> should it? Let's not spend energy or code on issues that don't matter.

My impression is that there are more and more people willing to use javascript and MathML (I just saw yet another message on the MathJax user list yesterday), and more specifically to write interactive MathML editor (e.g. see the recent HostMath spams on various mailing lists). I don't think most of them are currently interested in speed (they generally use MathJax to redisplay the whole formula at each change). However, I saw that optimization was at least important for this person who decided to stop using MathJax for that purpose:

http://www.stephendiehl.com/?p=237
http://www.stephendiehl.com/?p=224
http://www.stephendiehl.com/?p=254

But the real point of this report was really to fix the known bugs about dynamic MathML formulas. Indeed, even with this drastic reflow method used, some formulas are still not rendered correctly after DOM updates. So we should fix these bugs and I think it's worth trying to find other similar bugs that are likely to exist and to write nonregression tests for them. If at the same time we can optimize a bit the AttributeChanged function, that's even better.
Comment 3 Frédéric Wang (:fredw) 2014-03-20 08:22:28 PDT
Closing this meta bug.

Note You need to log in before you can comment on or make changes to this bug.