[Webkit-unassigned] [Bug 43516] REGRESSION: Huge number of memory leaks after enabling MathML

Fri Aug 6 04:26:24 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=43516

--- Comment #15 from Alex Milowski <alex at milowski.com>  2010-08-06 04:26:24 PST ---
I'm certainly open to other suggestions on how to approach operator stretch.  The general algorithm is if the operator height is above a certain threshold and is a stretchable operator, you stack glyphs using different glyphs for specific parts of the character's normal representation.  For example, a left curly bracket has glyphs for the top, bottom, middle, and extension.

When the element or stretch height changes, which can happen multiple times during layout of a row of mathematical constructs, the stretch height of the operator (i.e. the height of the containing row) will change.  Currently, we deal with this by assuming that the current set of stacked glyphs are invalid.  We then remove them from the render tree and re-stack the glyphs.

In the past, I've had strange issues when using document() for the backing node for the anonymous blocks.  These are briefly described here:

   https://lists.webkit.org/pipermail/webkit-dev/2010-February/011559.html

All these issues went away when I changed the backing node to be the operator node (e.g. mo element) itself.  Those particular issues were for mrow's rendering and I don't know if simply changing the backing node to document() in the glyph stack will make this anymore clear or similar to other render objects.

The technique of glyph stack is a fairly standard way to handle operator stretching when typesetting Mathematics.  In the end, we still need to stack glyphs.  With our current multi-pass row layout and the fact that the DOM can be changed at any time, I don't see how handle a change of height other than to delete the children and start over stacking a new set of glyphs.

I'm open to any suggestions but the current patch seems cleaner than what I had and also doesn't leak memory.  If it passes the tests, in my opinion, we should commit it.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.