The issue is a little more accentuated when using this in a table (see picture attached).

Deleted: translateZ_issue.png 35.3 KB

	translateZ_issue.png 35.3 KB View Download

Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest stable #60.0.3112.113 by following steps mentioned in the original comment.

Tested the same on chrome older version of M45-45.0.2454.85 and M50-50.0.2624.0 and observed different behavior

Reporter@ Attaching screen shot for reference, could you please confirm and let us know the behavior displayed in M45 is the expected one?

Thanks!

Deleted: 760375png.png 17.2 KB

	760375png.png 17.2 KB View Download

Yes, I believe the behavior in the older versions is correct, the text looks a little faded but at least it is consistent and it looks similar to other browsers like Firefox , IE etc.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Bisecting back to before we un-prefixed -webkit-transform will probably land at the un-prefixing patch.

Right now I'm getting errors loading the font for unknown reasons. The font thinning effect is present even on the default font.

Adding GPU raster label in the hope someone has an idea as to why this is.

Corrected test file.

Deleted: windows-opensans-issue.html 599 bytes

windows-opensans-issue.html 599 bytes View Download

Confirmed this is Windows only, so not likely anything in the Blink pipeline.

eae: It's expected behavior that when something is in a translateZ layer that we lose lcd text.  Is this visual difference here the kind of thing that you'd expect to see with text rendering on windows between lcd text and not?

Just curious if you think there's something else wrong here, or if this is expected.

The much thinner text is an unexpected side effect. Did we tweak how we render grayscale aa recently?