Thanks for Dominik's help, here's what we found so far: it's most likely to be a Skia issue.

The issue existed as early as July. It's only known to be reproducible on Peppy,Gnawty and Paine.

The issue doesn't exist on the buttons of the lock debug overlay. It doesn't exist in other places that use |TextField| (e.g. wifi password box). It doesn't exist in the name below the avatar.

Adding the flag 'disable-gpu-rasterization' does not help. Changing the font size does not help.

If we change the background color of the text field to a solid color, the black
shades are not visible, however they still exist if we change the color to be semi-transparent.

+Zach, could you help to triage this bug? It's most likely to be a Skia issue.

To marcheu@ for skia

I think you have me mistaken for a skia engineer :)  Hopefully Heather knows where to send this.

Hard to tell from the pictures, but looks like it may be LCD text rendering.  Skia has (for a long time) required LCD on opaque...or there is a special preserve saveLayer call that will override.  If the background is not opaque in that case, you will get a visual effect like the above when rendering on CPU.

Someone needs to look into how this is being done in the CrOS code, cc bungeman for consulting on Skia side.

re: #6 what you are describing seems like a bug. Is there a bug number already on this that I can track instead? If not, we can use this issue to track the bug.

bungeman@, according to hcm@, you're the lead for font/text. Could you investigate this and see if this needs to be fixed in Skia or the graphics stack on CrOS?


This bug can mask other visual issues that otherwise our dogfooders may report - hence bumping the release block to dev.

 Issue 787133  has been merged into this issue.

The camera shots make it difficult to be sure, but it appears this is subpixel (lcd) rendered glyphs. There is no correct way to composite such masks on anything other than an opaque background. The GPU and the newer raster pipeline blitters attempt to create the closest possible thing to mask this issue, but even then it isn't a great idea to rely on it. Skia's sse2 blitter for this case always forces the alpha to 1 (opaque). If you draw subpixel rendered glyphs onto a transparent black background, part of that background will become more opaque (even on GPU and the newer blitters). This is not new in Skia, this has been a limitation for a very long time.

Skia tries to prevent this by ensuring that when one makes a saveLayer call the layer is either opaque or kPreserveLCDText_SaveLayerFlag is set. Otherwise is will disable subpixel rendering, since it can't really be supported. kPreserveLCDText_SaveLayerFlag exists so that advanced users can draw subpixel rendered text to opaque regions of non-fully opaque layers (it is up to the user to ensure that they make such draws only to opaque regions). As a result, if this didn't used to happen on these devices and now does, this is probably the result of a change in user code to either mark the layer as opaque (when it isn't), set the kPreserveLCDText_SaveLayerFlag in the hope of getting subpixel rendered glyphs without understanding the requirements, or somehow moving from GPU to CPU rendering of these layers. It is vaguely possible that something may have changed in Skia so that it isn't turning off subpixel rendering when it should, but I don't believe there have been any recent changes in this area.

Hey Mike, bungeman@ believes this is an issue with Views using Skia incorrectly. He found [1] which has a comment that claim that SubPixel rendering requires an opaque background. If this is true, then for our use case, can we just turn off SubPixel rendering? Or any other solution you would suggest?

[1] https://cs.chromium.org/chromium/src/ui/views/controls/label.h?q=label.h&sq=package:chromium&l=117

Subpixel rendering definitely requires an opaque background, and you can definitely turn it off to use a transparent background.

wzang@, hopefully it's easy enough to call views::Label::SetSubpixelRenderingEnabled, as rkc@ notes.

Re #13, OK, that requires some plumbing code in |Textfield| as well. Will send you a CL on that.

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

commit e5559b223b99523ee32cd57cd6e59b9ec01dfff0
Author: Wenzhao Zang <wzang@chromium.org>
Date: Mon Nov 27 21:10:19 2017

cros: Turn off subpixel rendering for views-based lock screen

Bug:  786343 
Change-Id: I7bd5bfccfee25894499b9d1b9971691090b02ec5
Reviewed-on: https://chromium-review.googlesource.com/786267
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Wenzhao (Colin) Zang <wzang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519400}
[modify] https://crrev.com/e5559b223b99523ee32cd57cd6e59b9ec01dfff0/ash/shelf/login_shelf_view.cc
[modify] https://crrev.com/e5559b223b99523ee32cd57cd6e59b9ec01dfff0/ui/views/controls/textfield/textfield.cc

Verified on ChromeOS 10172.0.0, 64.0.3280.5