This still reproduces in Canary 56.

It looks like the multiple text-shadows are being represented as copies of the emoji instead of the expected solid color. Here is a reduced example of the problem: http://output.jsbin.com/qenuro

On desktop Chrome, I see the emoji in the top left, and then red, green and blue silhouettes of those emoji.
On Android Chrome, instead of silhouettes, I see multiple copies of the emoji.

text-shadow does not use CSS filter effects.

BTW, the repro in #3 goes away when GPU rasterization is disabled (also goes away in 53, perhaps due to the viewport veto). So this looks like it might be a GPU raster bug.

+bsalomon to see if he has thoughts on the cuase... Seems likely that the shader which generates the shadow is supposed to be sampling the emoji's alpha only (and using that to mask the shadow color), but instead is passing through the color as well?

Note that this *only* reproduces with emoji - when normal text is used we get the desired behavior with GPU raster.

I'm able to repro this on Windows 10 and have a SKP from the page. The bug repros in SKP playback on GPU but not SW.

Deleted: layer_58.skp 46.1 KB

layer_58.skp 46.1 KB Download

This is a stripped down repro skp.

Deleted: emojibug.skp 1.2 KB

emojibug.skp 1.2 KB Download

There is no blur here but rather several draws of the emoji glyph with color filters installed. The problem is this line:

https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/text/GrAtlasTextContext.cpp?q=GrAtlasTextCont&sq=package:chromium&l=127

There are various versions of SkPaintToGrPaint* functions and the appropriate one to use here depends on whether the text is color bitmap text or not. The one called here is appropriate for non-color text. It sees a SkPaint with no SkShader and thinks it can apply the color filter once to the paint color rather than in the fragment shader. However, this isn't correct for emoji text since the glyphs themselves have variable color. I think there is a related bug (not manifested in this example) where for emoji text we should ignore the SkPaint's SkShader if there is one since the glyph bitmap supplants the shader (as though drawBitmap were called).

I don't think we know here whether it is a color text draw or not at this point. Even worse the text run can have a mix of color and non-color glyphs. I think the fix is to delay doing this conversion until we have separated gylphs by how they will be rendered (color bitmap, lcd mask, or grayscale mask).

BTW, the captured SKP will probably only repro this on Win10 since it contains a platform/font-specific glyph id.

This was fixed by this change:

https://skia.googlesource.com/skia/+/6f1d36cc54dc635f5e4d0f925ef79c14914342bb