In discussion with fmalita@ see proposed change as:

http://crrev.com/1891443004

Note from fmalita@:

SkPaint::measureText() is the canonical API, converting to a path is convoluted and also apparently less accurate.  Initially (WebKit days) we were using measureText(), but then https://codereview.chromium.org/25045010 changed to path bounds due to vertical text snugness concerns.  It's probably time to revisit.

The Linux & Win diffs for http://crrev.com/1891443004 look mostly OK to me (expected minor measurement text diffs, some emphasis mark juggling).

Mac OTOH shows a lot more variance, and some obvious regressions: https://storage.googleapis.com/chromium-layout-test-archives/mac_chromium_rel_ng/211664/layout-test-results/results.html

I recall while trying to use the glyph overflow data for text blob bounds Jeremy also ran into some issues with OSX fonts.  Maybe a Skia problem with Mac fonts?

I'm also surprised that SimpleFontData::boundsForGlyph affects layout/sizing at all - I thought we only use that info for overflow / visual rect / culling logic.

I don't recall the exact issue, that sounds right. I think some of our issues back in the day came from the simple text path not being as bright as the HarfBuzz one, so we should at least be better off now than we were then.

Waiting on fmalita@ looking into the change I linked in comment #1 so transferring ownership to him.

I thought the Mac diffs are unexpected, so I tried an experiment: expand the glyph bbox unconditionally by {5, 5, 10, 10} to see which tests are affected on various platforms (https://codereview.chromium.org/1889793006/#ps40001)

With this change, I can repro most of the Mac diffs on other platforms also.

Unfortunately this indicates that the Mac glyph bounds as returned by SkPaint::measureText() are inaccurate.  Ben also mentioned that glyph bounds are known to be unreliable on Mac - I guess the surprising part is that getTextPath() produces better results than measureText().   Ben/Mike - is that expected or something we can improve in Skia?

Unless we find some way to fix measureText bounds on Mac, there are too many side-effects to land this change short-term (and Walter may need to look for a workaround for his original issue).



---
(tangent)


Since I did not expect glyph bound deltas to cause significant visual diffs (I was assuming they're mostly used for visual overflow/culling stuff), here's a (mostly speculative) list of observed side effects:

1) emphasis mark positions - this makes sense: we use the glyph bounds to center them

e.g. https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_rel_ng/216980/layout-test-results/fast/text/emphasis-combined-text-diffs.html


2) composited content - it makes sense that the layer geometry depends on visual overflow, but the actual composited result/position should not be affected;  I suspect this is causing subtle layer size/position changes and we're tickling one of the subpixel layer bugs (issue 521364?)

e.g. https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_rel_ng/216980/layout-test-results/compositing/text-on-scaled-layer-diffs.html


3) outline geometry - the outline rect is based on visual overflow; kinda makes sense.

e.g. https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_rel_ng/216980/layout-test-results/svg/custom/focus-ring-text-diffs.html


4) filters - the filter effect region depends on visual overflow; also makes sense

e.g. https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_rel_ng/216980/layout-test-results/svg/filters/filter-on-tspan-diffs.html


5) 'ex' CSS unit - looks like we're computing x-height based on actual glyph bounds instead of a font property;  this doesn't seem right.

e.g.  https://storage.googleapis.com/chromium-layout-test-archives/mac_chromium_rel_ng/215637/layout-test-results/css1/units/length_units-diffs.html


6) vertical positioning - seems to come into play mostly for combined text; not sure why the glyph bounds have side-effects here

e.g. https://storage.googleapis.com/chromium-layout-test-archives/win_chromium_rel_ng/209509/layout-test-results/fast/text/decorations-with-text-combine-diffs.html

Per conversation with Ben, there's some work going on in Skia to improve the Mac glyph bounds accuracy - but it's not going to land soon.

@wkorman I think it's safe to say the measureText() approach is not feasible at this point (on Mac).  To unblock the original CL it's probably better to revisit your workaround idea (expand the cull rect in device space).

I'll open a separate bug to track measureText-on-Mac issues.

Per discussion on http://crrev.com/1957563002 plan to rebaseline the one affected test and defer further work to resolution of the text measurement / glyph bounds issue discussed above. I'll dupe this bug to the new one fmalita@ mentions.