Able to reproduce the issue on mac 10.12.2 chrome version 56.0.2924.59 and canary 57.0.2984.0 - Text is barely legible as shown in the screenshot

This is a regression as this was working fine in stable 55.0.2883.87

This is working in win and linux OS

This issue is specific to mac retina


Manual Bisect Info:
Good build : 55.0.2883.105
Bad Build : 56.0.2884.0

Bisect tool is invoking all good builds though increased the  bad range. Hence giving the manual CL

CL : https://chromium.googlesource.com/chromium/src/+log/55.0.2883.0..56.0.2884.0?pretty=fuller&n=10000

Possible suspect : https://chromium.googlesource.com/skia.git/+/3786c7716c4796146835e60d7145cff252ed50bd

Please reassign if this is not related to your change.

Adding people who actually know things.

It appears that Skia is being asked to draw a textBlob that has a run with LCD text specified. Unfortunately, the surface it is being drawn into isn't opaque which winds up altering the pixels around the text.

AFAIK Skia always trusts the caller to only use LCD text when the destination is known to be opaque.

Note that this will repro on Linux if "--force-gpu-rasterization" is used.

I think we also look at the SkPixelGeometry on the SkSurface's SkSurfaceProps. But if the client specifies a SkPixelGeometry other than kUnknown and sets the blob to be LCD then we don't question it.

On Linux with force-gpu-rasterization, the SkGpuDevice is reporting a pixelGeometry of kRGB_H_SkPixelGeometry right before diving into the drawTextBlob method.

In general, we are supposed to disable LCD text for all non-opaque surfaces - e.g.: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/AcceleratedImageBufferSurface.cpp?rcl=70fb26c9646660021ce780f6e4849b22688975c9&l=58

Sounds like some surface factory is missing this logic?

It may have something to do with the new 'alpha' parameter to getContext

Can we get some action on this. Seem fairly simple to fix and we now have a 30-day SLA for P1 issues.

If you point me to the right surface creation method, I can try to fix it.

 Issue 714428  has been merged into this issue.

According to duplicate issue, regression range is: https://chromium.googlesource.com/chromium/src/+log/52.0.2743.0..53.0.2744.0?pretty=fuller&n=10000

A narrower range would be useful.

I can get a narrower range.

I don't think this is a regression. On linux, when using --force-gpu-rasterization this reproduces all the way back to M-53. I suspect the test teams' bisects are just finding the time that their machine was whitelisted for GPU raster, or something like that.

I can't repro on my Mac at all.

Reducing the priority accordingly.

Disabling deferral for text rendering should fix this for now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee1c820d0133c0536a55b5a0aaf808a97c471bde

commit ee1c820d0133c0536a55b5a0aaf808a97c471bde
Author: fserb <fserb@chromium.org>
Date: Mon May 15 17:07:12 2017

Disable 2D canvas deferral on text rendering when compositing

SkPicture currently has a hard time realizing a surface change may mean
a LCD font rendering change. So we can't send deferred SkPicture when
drawing texts

BUG= 682074 

Review-Url: https://codereview.chromium.org/2877833002
Cr-Commit-Position: refs/heads/master@{#471808}

[modify] https://crrev.com/ee1c820d0133c0536a55b5a0aaf808a97c471bde/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/ee1c820d0133c0536a55b5a0aaf808a97c471bde/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2D.cpp
[modify] https://crrev.com/ee1c820d0133c0536a55b5a0aaf808a97c471bde/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp

Please double check on ToT, or on canary in a couple days.
It should be perfect. ;)
Reopen if anything seems weird. PEACE!

 Issue 729363  has been merged into this issue.

 Issue 718113  has been merged into this issue.

 Issue 737080  has been merged into this issue.