Comment 42 for bug 345207

(In reply to comment #21)

> Even better than a property would be not storing the values at all and simply
> calculating them on the fly. All you really need is the starting point of the
> first glyph (mPosition) as that may depend on where the previous frame left you
> and so would be O(N2). Everything else you should be able to calculate using
> GetParent where necessary. If we find it is unacceptably slow we can always add
> caching of the positions in later.

The code is already slow.

mPosition only stores the first glyph position. No problem if everything is a
simple text run and no inherited x,y,dx,dy lists.

To support your contrived example in Comment #20,

> <text x="1 2 3 4 5" y="4 5 6 7">h<tspan dx="5
> 6">e<tspan>l</tspan>lo</tspan></text>

even having mPosition for each fragment, you still have to determine if layout
calculations are required. That means going out to the current text element,
checking for inherited lists and then re-layout (calculate) each GlyphFragment
until you get back to the one you want the positioning for. In the example
above, determining the position of 'o' requires this action.

There would be a significant performance hit for painting the contents of a
text element using nsSVGGlyphFrame::PaintSVG(). For each successive glyph
fragment in a text element you would have to go back and check/recalculate all
the previous fragments. Resizing the browser window with a lot of text in the
document will become slower than it is. I can't see how SMIL animation of text
could ever be acceptable.

> This article explains where we were and what we're trying to avoid :-)
> http://weblogs.mozillazine.org/roc/archives/2006/02/anatomy_of_bloat.html

The article seems to point the finger mostly at XPCOM objects.

>
> I think it should be possible to get rid of everything except the mPosition
> member variable (although getting rid of the whitespacehandling member belongs
> in another bug).
>

Why even keep mPosition? or do UpdateGlyphPositioning() at all? or have
mPositioningDirty ? Just recalculate everything on demand.

Seriously, it would be helpful to understand how decisions are made regarding
bloat vs performance. Are there general guidelines I can use or is it hit or
miss at every patch?