Use glyph-ids for lookups of SVG font kerning-pairs

Use glyph-ids for lookups of SVG font kerning-pairs

This CL eliminates the SVGTextMetrics::Glyph class in favor
of a simple Glyph (glyph-id). This shrinks SVGTextMetrics
objects by two pointers, and avoids the allocation of tiny
(often single-character/code-unit) strings.

It achieves this by replacing the linear kerning-pair lookup
with a table (HashMap) indexed by a key made up of the glyph id's of the two glyphs.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=168007

[fs, 2014-02-26 13:16:47]

Straight from the "Waiting for Godot"-department...

While waiting for the demise of SVG fonts, we can reduce their
impact on interfacing code - and memory usage - a bit by doing
this relatively simple change.
What it amounts to is looking up kerning-pair using glyph-ids
instead of the (rather heavey-handed IMHO) current way that
uses both a copy of the code-units and possibly a glyph-name
found during character->glyph mapping.

Pros:
 * Gets rid of the copies of code-units and the glyph-name
   reference. (2*sizeof(pointer) + ~sizeof(StringImpl) less
   memory used per glyph within SVG <text>)
 * Gets rid of WidthIterator::lastGlyphName.
(* Faster lookup of kerning-pairs.)

Cons:
 * Slower to construct the SVG font. (Need to spend additional
   time building the kerning table/map. Could be improved
   somewhat, but I didn't feel it was warranted up-front.)
 * Potentially uses more memory (for table-storage).
 * Probably a net-increase in code-size.

I've uploaded the patch in portions to potentially help
seeing the different parts:

PS1: Rename of the 'id'-map to not use glyphName (since that's
     easy to confuse with the actual glyph-name).
PS2: Add the code to build and query the glyph-id based
     kerning-table.
PS3-4: Drop the old kerning lookup and plumb the glyph-ids
     through everywhere instead of the
     SVGTextMetrics::Glyph/Strings.

(And, no regressions observed for LayoutTests/svg.)

So, what do you think - keep on waiting or land? =)

[Stephen Chennney, 2014-02-26 19:52:01]

I think the trade-offs are worth it. It also makes the code easier to
understand, I think.

LGTM.

[fs, 2014-02-27 09:38:24]

On 2014/02/26 19:52:01, Stephen Chenney wrote:
> I think the trade-offs are worth it. It also makes the code easier to
> understand, I think.
> 
> LGTM.

Thanks. Dropping the "[RFC]" and landing.

[fs, 2014-02-27 09:38:31]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2014-02-27 09:38:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/fs@opera.com/181443002/80001

[commit-bot: I haz the power, 2014-02-27 10:28:45]

Change committed as 168007