See if we can cache text measurements

[pcwalton]

We spend about 25% of our time during reflow in lipsum re-measuring text. We can probably do something clever to cache this. (What do Gecko and WebKit do?)

[burg]

The obvious thing to do is to make a side table which stores precomputed widths of contiguous glyph ranges between hyphenation or line break opportunities. I'm not sure whether this will scale well once we consider line breaks at more places than just whitespace.

On Nov 10, 2012, at 10:33 , Patrick Walton wrote:

We spend most of our time during reflow in lipsum re-measuring text. We can probably do something clever to cache this. (What do Gecko and WebKit do?)

—
Reply to this email directly or view it on GitHub.

[rocallahan]

In Gecko we cache preshaped "words" (delimited by whitespace) --- this includes not just advance widths but also glyph IDs and positions. Then for a given DOM we build a set of "text runs" --- runs of text with the same font, size, style etc, possibly spanning DOM node node boundaries --- where a text run contains the advance widths, glyph IDs and positions obtained from the words in the text run.

[burg]

@rocallahan That is basically what's implemented, modulo the ShapedWord cache. It seems that the most costly part of the profile is spent summing advances during line breaking, since it's a page full of text. I was able to reduce the time a bit more with some inline hints.

[mbrubeck]

We now have a shaped word cache, and #8990 added caching of advances at various levels.