Same here.

Chrome version: 60.0.3112.78  Channel: stable
OS Version: Ubuntu 17.04

Deleted: 2017-07-26-125456_1280x1024_scrot.png 72.5 KB

	2017-07-26-125456_1280x1024_scrot.png 72.5 KB View Download

From the screen capture in comment 1 it is obvious that this is due to post-scaling the already rastered content. In the omnibox bar of the screen capture in comment 1 the text is subpixel anti-aliased, and the subpixel anti-aliasing has been resampled across multiple pixels (there should be exactly one 'reddish' pixel on the right edges of glyphs, but instead there are two). As a result this is an issue at compositing and after, it isn't a font rendering issue (if there is a font rendering issue, we can't really see it here anyway due to the resampling). Everything is affected, but it will be most obvious with thin lines and line art (which is what text is).

It would be good to know which desktop compositor you are using (in particular gnome3?), what your dpi settings may be, and what zoom level might be in effect in Chrome.

This is probably the same as issue 748730.

bungeman@, could you dupe or reroute this as appropriate? Thanks!

Routing best I know how.

I'm using standard Unity on Ubuntu, nothing fancy, and no zoom either.
Besides, Chromium 59 is still functioning perfectly well.
I suspect that the problem is present on all Linux distros, but I haven't checked.

Can anyone affected attach a copy of their about:gpu page?

Does the problem happen consistently if you resize the window?

This looks like it may affect a lot of people, but not everybody.
If we can repro in-house, we should be able to bisect.

If anyone who is affected is willing to help us by running a bisect on their machine, you can see instructions at https://www.chromium.org/developers/bisect-builds-py (good revision would be 3071, bad revision would be 3112).

I managed to reproduce it on all my machines (including laptops). 
Have you tried switching off aliasing system-wide? Without it, it will be very hard to detect the problem. 
I'm attaching the "fonts.conf" file that does exactly that. If you put it in ~/.config/fontconfig/, any Linux distro will understand it as a command to switch off the AA.

Deleted: fonts.conf 562 bytes

fonts.conf 562 bytes Download

Thanks for the config file. I repro on 60 stable, but not on the current dev (61).

Bisected the failure to https://chromium.googlesource.com/chromium/src/+/5cfc439201cc3a8700c9b202d6a53c78b362baf0

Reland: Statically link own version of FreeType on Linux

For color font support, CFF and CFF2 rasterization, and OpenType font
variations, latest security fixes, Chrome needs an up-to-date version of
FreeType (more details on the bug). Since distributions are too far
behind in the shipped system FreeType versions, we need to start linking
in our own copy.

For distributions that build their own Chromium this CL introduces a
switch use_system_freetype which can be used to keep the old linking
configuration at the expense of risking introduction of text rendering
and security regressions if the system FreeType is too old.

Reland with fixed installer dependency expectations, after revert
in https://codereview.chromium.org/2868793004/

TBR, because previously reviewed in
https://codereview.chromium.org/2863063003

BUG= 274030 
TBR=thomasanderson, dpranke

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


I also bisected the fix to https://chromium.googlesource.com/chromium/src/+log/20915a8562a48d5047895eb0c5daf517f4bd71ba..5c463fc47c620683111783b7ceafca60df2b6264 , which includes a freetype roll as the most likely candidate:

https://chromium.googlesource.com/chromium/src/+/4d6320ef3dee4ac9f29055b6b9d75497ea67796f

Roll src/third_party/freetype/src/ a12a34451..7819aeb62 (58 commits)

https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+log/a12a34451a99..7819aeb622a9

$ git log a12a34451..7819aeb62 --date=short --no-merges --format='%ad %ae %s'
2017-06-28 bungeman Avoid Microsoft compiler warnings (#51331).
2017-06-27 wl * src/cff/cffparse.c (do_fixed): Fix typo.
2017-06-27 wl [truetype] Integer overflows.
2017-06-24 wl [truetype] Integer overflows.
2017-06-22 wl [cff, truetype] Integer overflows.
2017-06-21 apodtele [sfnt] Synthesize a Unicode charmap if one is missing.
2017-06-20 wl Remove deprecated comment.
2017-06-20 tonyt Fix pkg-config in freetype-config for cross-compiling (#51274).
2017-06-20 wl [cff, truetype] Integer overflows.
2017-06-17 apodtele [base, smooth] LCD filtering cleanups.
2017-06-16 wl [truetype] Integer overflows.
2017-06-15 wl [bdf, cff] Integer overflows.
2017-06-14 wl * src/winfonts/winfnt.c (FNT_Face_Init): Don't set active encoding.
2017-06-13 wl [cff, truetype] Integer overflows.
2017-06-11 wl [cff] Integer overflows.
2017-06-10 wl [truetype] Fix TT_Set_Var_Design.
2017-06-10 wl * src/base/ftcalc.c (FT_DivFix): Fix embarrassing typo.
2017-06-09 wl [cff, truetype] Integer overflows.
2017-06-09 wl Provide more macros for flooring, ceiling, and rounding.
2017-06-09 wl Remove unused macros.
2017-06-09 wl */*: Remove `OVERFLOW_' prefix.
2017-06-07 wl [cff, truetype] Integer overflows.
2017-06-06 wl [cff] Integer overflow.
2017-06-05 wl [cff] Integer overflow.
2017-06-04 wl [cff, truetype] Integer overflows.
2017-06-03 wl [base, cff, truetype] Integer overflows.
2017-06-03 wl * builds/unix/freetype-config.in: Fix pkg-config test (#51162).
2017-06-03 wl [bdf] Synchronize sanity checks with pcf driver.
2017-06-03 wl [cff, truetype] Integer overflows.
2017-06-03 wl ftcalc.h: Avoid left-shift of negative numbers.
2017-06-02 wl [cff] Even more integer overflows.
2017-06-02 wl [cff] More integer overflows.
2017-06-02 wl [bdf] Don't left-shift negative numbers.
2017-06-02 wl [bdf] Fix integer scanning routines.
2017-06-02 wl [cff] Fix integer overflows.
2017-06-01 wl [smooth] Some 32bit integer overflow run-time errors.
2017-06-01 wl Minor comment.
2017-06-01 wl * src/base/ftglyph.c (FT_Get_Glyph): Check `slot->advance'.
2017-06-01 wl [psaux] 32bit integer overflow tun-time errors (#46149).
2017-06-01 wl * src/truetype/ttinterp.c (TT_RunIns): Adjust loop counter again.
2017-05-31 wl [cff] 32bit integer overflow run-time errors 2/2 (#46149).
2017-05-30 wl [cff] 32bit integer overflow run-time errors 1/2 (#46149).
2017-05-30 wl [psaux] Correctly handle sequences of multiple number signs.
2017-05-29 wl [pcf] 32bit integer overflow run-time errors (#46149).
2017-05-29 wl Handle some integer overflow run-time errors (#46149, #48979).
2017-05-28 wl * include/freetype/internal/ftcalc.h (FLOAT_TO_FIXED): Remove.
2017-05-28 wl [cff] s/cf2_floatToFixed/cf2_doubleToFixed/.
2017-05-28 wl Fix negation of INT_MIN and LONG_MIN (#46149).
2017-05-27 wl [truetype] Fix handling of design coordinates (#51127).
2017-05-24 wl [bdf, pcf] Support ISO646.1991-IRV character encoding (aka ASCII).
2017-05-20 madigens [truetype] Always use interpreter v35 for B/W rendering (#51051).
2017-05-20 apodtele [smooth] Implement minimal dynamic padding for LCD filtering.
2017-05-17 wl [autofit] More code sorting.
2017-05-17 wl Code sorting.
2017-05-15 wl [sfnt] Return proper scaling values for SBIX bitmaps.
2017-05-15 wl [truetype] Fix error handling for embedded bitmaps.
2017-05-15 apodtele [autofit] Make autohint warping NORMAL option.
2017-05-14 wl Remove remnants of raster pool.

Created with:
  roll-dep src/third_party/freetype/src
R=wangxianzhu@chromium.org,michaelbai@chromium.org,bungeman@chromium.org,drott@chromium.org

Change-Id: I3e5740eab26f174b3281e623855814ebc711ba8e
Reviewed-on: https://chromium-review.googlesource.com/550379
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483453}


@drott, bungeman: What can we do that would be safe to roll to stable (assuming we can respin)?

Indeed, I just installed an unstable build from the repo (61.0.3159.5), and it's definitely much better than 60. For some reason, though, letters like "W", "M", "N" look worse than in Chromium 59.

Deleted: chrome-menu-59.png 5.2 KB

	chrome-menu-59.png 5.2 KB View Download

Deleted: chrome-menu-61.png 5.1 KB

	chrome-menu-61.png 5.1 KB View Download

 Issue 749004  has been merged into this issue.

Note that the significant change to FreeType in the list in Comment #10 is

2017-05-20 madigens [truetype] Always use interpreter v35 for B/W rendering (#51051).


However, Skia in m60 can't handle the change that comes right before that

2017-05-20 apodtele [smooth] Implement minimal dynamic padding for LCD filtering.

with out cherry-picking Skia change 6cdb5f2ad7684302a8a66217462d2aef4c5f4632 first.

Note that over on  issue 726631  (which was fixed by the FreeType roll mentioned in Comment #10) there are also a number of users clamoring for a backport of this roll. Since this is the same issue as that, I'll dupe this one and work on backporting there.

I think I'm also affected by this on Chrome 60. Not sure if any more reports are needed, but posting in case it helps. 

It seems to affect text that has an alpha channel less than 1. When I saw it occurring again, I opened dev tools and forced the alpha channel on its color CSS property to 1, and it went away. I can't reproduce it reliably, as it goes away with little pattern on its own. I have attached an example of what it looks while the text rendering is incorrect, when it is (solid white text), and my about:gpu output.

Deleted: gpu.html 244 KB

gpu.html 244 KB View Download

Deleted: Screenshot from 2017-07-29 08-00-20.png 1.7 KB

	Screenshot from 2017-07-29 08-00-20.png 1.7 KB View Download

Deleted: Screenshot from 2017-07-28 12-56-47.png 1.7 KB

	Screenshot from 2017-07-28 12-56-47.png 1.7 KB View Download