This might be a fonts issue. The repaint rect on the sailboat text glyph (https://www.utf8icons.com/character/9973/sailboat) is off by a pixel at the top. I'll bisect to see if I can identify when it broke.

Doesn't repro on Linux but the font is also different there.

Oddly, I can reproduce this in Chrome Canary 61.0.3141.0, but I couldn't reproduce in Chrome 59.0.3071.82 nor 60.0.3112.50. Trying to bisect shows it always happening in Chromium.

I maintain that the paint rect must be off by a pixel at the top. Maybe we are snapping or rounding poorly.

Should test with rotation removed as well (to test the reporters theory.) Besides snapping or rounding poorly this could also be a matter of our "height" approximation (or other metric in that dimension) not being good enough.

I did a bisect and ended up with skia change log.

https://chromium.googlesource.com/chromium/src/+log/2127e6fa797bf51e4d0b3f2363c94c78d53c9b73..9c6667bfa38b7252dc66e486744e8b8ee56f0ec2

Good Build: 59.0.3032.0
Bad Build: 59.0.3071.115

msarett@, could this be related to your change (https://skia.googlesource.com/skia.git/+/06b302585c35000642898752a6d4e7cf5b67ceac) ?

Thank you!

Is msarett@chromium.org still around, or on leave?

he's gone... will get some others to look but we've got a number of folks out right now and tackling many P1s

The change mentioned in Comment #8 ( https://skia.googlesource.com/skia.git/+/06b302585c35000642898752a6d4e7cf5b67ceac ) is a change in some color space code, it has nothing to do with where things show up on screen. On the other hand, I don't see anything in that roll which would have any effect here.

That being said, this is likely similar to issue 596223. Skia will always report what size it will draw if asked exactly (and it will never draw outside of those bounds). However, I believe there are bits of Blink which believe that if a typeface is measured at one size, that this measurement can be freely scaled up and down to produce bounds. This is incorrect, and Apple Color Emoji in recent versions goes out of its way to make smaller glyph sizes much larger than one would expect from linearly scaling down the larger sizes.

As a result it is quite possible that Skia is drawing in the bounds it would report for these glyphs, but Blink is using too small of an invalidation because it sized the "text" svg element smaller than the glyph it actually ended up drawing. 

On my machine this is also an issue with Safari (as is pointed out in the original report). Also note that this depends on the version of the Apple Color Emoji font which is active. This isn't really an issue with Skia, but with bits of Blink assuming that certain font metrics can be scaled independent of the final raster scale.

The only way for Skia to help "work around" this would be to always draw bitmap fonts at the exact size Blink originally states and then always scale that particular strike linearly in Skia. However, this would result in rather poor handling of color emoji, particularly on Mac. Note that the same issues can occur with heavily hinted fonts as well, though that is less likely (and less likely to be seen for various reasons).

Thanks for all the info. Much appreciated. We'll take it from here.

Looks like it's fixed, at least the given example no longer leaves residual paint.

Reopen as per https://bugs.chromium.org/p/chromium/issues/detail?id=845711#c14.

Bisected to https://chromium.googlesource.com/chromium/src/+log/fed17b05d47e20ee24616f955c75b843560c1546..95989cb55f0f86b5961834c0dcb048f816510b9b

Suspecting https://chromium.googlesource.com/chromium/src/+/40ae08bc002c3cda5737b7c7c0b6567714c22ff4
ccameron@ can you take a look?

If not GPU rasterization, the root cause might still be as stated in #c12 and #c13.

I just noticed another bug and filed  bug 848616 .

Bisected the range between M-61 and M-66 to locate which CL ever fixed the bug:
https://chromium.googlesource.com/chromium/src/+log/3451ba871c58199f1fbd5e1e9562cb61f71e259c..77d8321dd47aacebb81be856685c55688853f27e
It may be the skia roll (2017-11-09 liyuqian Compute more accurate containedInClip?).

The current bug seems a bit different from the bug in M-61. Now the "smoke" looks lighter. It seems that some antialiased pixels overflows the rect that blink thinks should contain the rasterized glyph.

Un-assigning -- this might be a damage tracking bug in canvas or skia?