blurry fonts after upgrade to v69 or v70 from v68
Reported by
vkr...@gmail.com,
Oct 25
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. Upgrade to google chrome from 68.0.3440.106 to 69.0.3497.81 or any of the stable 70.0.3538.77 version on openSUSE Leap 15.0 via zypper. 2. Open mytabletennis.net on v68 and (v69 or v70) 3. Look at the font in url bar 4. Look at the fonts under "Latest posts" What is the expected behavior? See screenshots attached to issue 881230 . What went wrong? v69 and v70 font rendering is blurry. Did this work before? Yes 68.0.3440.106 Chrome version: 70.0.3538.77 Channel: stable OS Version: openSUSE Leap 15.0 Flash Version: I am refiling this defect as requested by "osh…" in comment #120 to issue 880513 because issue 881230 was merged into issue 880513 as "duplicate" and then issue 880513 was marked as closed but my issue was not resolved. Other people commented in #881230 that it is not a duplicate of #880513. I am really frustrated at Google Chrome being the only GTK application suffering constant font rendering regressions. This simply does not happen in Firefox, Thunderbird or Eclipse.
,
Oct 26
Thanks for filling the issue... Able to reproduce the issue on reported chrome version 70.0.3538.77 also on latest chrome 72.0.3589.0 using Ubuntu 14.04 and Mac 10.14.0. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Note: Issue not seen on Windows and Removing Needs-Bisect label to it. Attaching screenshots for reference. Thanks!
,
Oct 26
Umm, my report is about a regression in v69 and v70 as compared to v68, not v60.
,
Oct 29
,
Nov 5
,
Nov 5
Might be hardware font rendering. But to me the screen shots just differ slightly in where the characters are positioned. My M-71 on linux does not sub-pixel anti-alias, so does not show the same effect. I thought it might be compositing moving layers around, but there is only one layer for the entire page (except ads).
,
Nov 5
vkrevs@, could you please include your screenshot and point exactly what's the issue is? It may be obvious to you, but unless we see it, we can really tell.
,
Nov 5
The screenshots including the output from derat's font-config-info are attached to issue 881230 .
,
Nov 5
Please post it here. It's different issue and we do not want to mix them.
,
Nov 5
,
Nov 5
Hmm. Looking at the text under "Latest posts" in the two images in #10, the differences are subtle. Subpixel rendering is used in both, but the text looks like it's more strongly hinted in the M68 screenshot. Vertical strokes are more likely to be spread across multiple columns in the M69 screenshot; see e.g. 'T' characters. I don't know if this is a hinting difference per se or if it's instead caused by e.g. gamma changes.
,
Nov 6
Agree with your analysis, derat@ - hard to tell whether it's a hinting change or other rendering difference. Looking at the left column of the table tennis site, there are spacing differences, too. And spacing in 69 looks improved, more homogeneous, compared to 68.
,
Nov 6
Forgot to attach higher-resoluition screenshots from my work 3440x1440 monitor (from comment 9 in issue 881230 ). Fonts in latest 69.0.3497.92 are still blurry and a bit squished together as compared to 68.0.3440.10.
,
Nov 6
,
Nov 9
I have 68.0.3440.106 and 69.0.3497.92 locally, and set things up so my font configuration was pretty close to the one provided. In my case 68 and 69 both appear to render the same, but more like the v69 screen capture (though oddly not exactly in the hinting, maybe different font versions of Arial and Verdana?) and not like the v68 screen capture. I'm not sure how to reproduce this and it may be something specific to the exact setup and versions of the fonts, and there are a lot of changes in this range. If someone can reproduce, the first step is to run bisect-builds as documented at https://www.chromium.org/developers/bisect-builds-py which in this case boils down to $ curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -d > bisect-builds.py $ python bisect-builds.py -a linux64 -g 561733 -b 576753 --verify-range --use-local-cache -- --no-first-run --user-data-dir=/tmp http://mytabletennis.net and tell it which builds are good or bad and paste the output here. This should narrow the changes we need to consider to some reasonable number.
,
Nov 9
,
Nov 10
$ curl -s --basic -n "https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py?format=TEXT" | base64 -d > bisect-builds.py $ python bisect-builds.py -a linux64 -g 561733 -b 576753 --verify-range --use-local-cache -- --no-first-run --user-data-dir=/tmp http://mytabletennis.net Downloading list of known revisions... Saved revisions 41523-607124 to /data4/tmp/chromium/.bisect-builds-cache.json Downloading revision 561736... Received 105422097 of 105422097 bytes, 100.00% Trying revision 561736... Revision 561736 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 576753... Trying revision 576753... Revision 576753 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 569889... Bisecting range [561736 (good), 576753 (bad)], roughly 13 steps left. Trying revision 569889... Revision 569889 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 565984... Bisecting range [561736 (good), 569889 (bad)], roughly 12 steps left. Trying revision 565984... Revision 565984 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 567906... Bisecting range [565984 (good), 569889 (bad)], roughly 11 steps left. Trying revision 567906... Revision 567906 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 566969... Bisecting range [565984 (good), 567906 (bad)], roughly 10 steps left. Trying revision 566969... Revision 566969 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 567507... Bisecting range [566969 (good), 567906 (bad)], roughly 9 steps left. Trying revision 567507... Revision 567507 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 567212... Bisecting range [566969 (good), 567507 (bad)], roughly 8 steps left. Trying revision 567212... Revision 567212 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 567110... Bisecting range [566969 (good), 567212 (bad)], roughly 7 steps left. Trying revision 567110... Revision 567110 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 567174... Bisecting range [567110 (good), 567212 (bad)], roughly 6 steps left. Trying revision 567174... Revision 567174 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 567140... Received 105854066 of 105854066 bytes, 100.00% Bisecting range [567110 (good), 567174 (bad)], roughly 5 steps left. Trying revision 567140... Revision 567140 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 567123... Received 105851482 of 105851482 bytes, 100.00% Bisecting range [567110 (good), 567140 (bad)], roughly 4 steps left. Trying revision 567123... Revision 567123 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 567130... Bisecting range [567123 (good), 567140 (bad)], roughly 3 steps left. Trying revision 567130... Revision 567130 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 567125... Bisecting range [567123 (good), 567130 (bad)], roughly 2 steps left. Trying revision 567125... Revision 567125 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b You are probably looking for a change made after 567123 (known good), but no later than 567125 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/27c6768e03b5e6fb190ece5e0bb68b60240cad5a..6b91daa8df790da14d7ba894b7c769a227736653
,
Nov 10
Based on the bisect, I'm pretty sure this is due to https://skia.googlesource.com/skia.git/+/d34b8a80f30a176ecf1c01ae7220b5f8af636eb8 . Before this change a request for "hintfull autohint (subpixel anti-alias rendering)" would result in the Skia FreeType request for "normal autohint (subpixel-antialias rendering)". After this change the request for "hintfull autohint (subpixel anti-alias rendering)" will make the Skia FreeType request for "lcd autohint (subpixel rendering)". In FreeType the "lcd autohint" mode is (documented to be) more or less light autohinting, which is different from full autohinting which is more aggressive. So in m68 this text was displayed from full autohinted glyphs with subpixel antialiasing (as if hintfull were downgraded to hintmedium when antialiasing was requested), in m68 this text was displayed from slight autohinted glyphs with subpixel antialiasing. Looking at the font-config-info.txt at https://bugs.chromium.org/p/chromium/issues/detail?id=881230#c5 , it appears that autohinting is being requested by the FontConfig defaults, which explains the setup. So now I can reproduce the changes by ensuring requests for hintfull autohinted rgb. It also means that you should get the previous behavior on this page by setting Arial and Verdana (the fonts the page is requesting and apparently getting) to hintmedium instead of hintfull. I'll need to see what other apps do in this situation and see what FreeType actually does with FT_LOAD_TARGET_LCD. This change was actually made because previously Skia wan't acting like other apps in this regard. Seeing that you appear to have Tahoma I'm assuming that you are getting Arial and Verdana from the webcore-fonts package which I think has really old (pre-cleartype hinted) versions of these fonts, which may be playing into why this was seen on opensuse.
,
Nov 12
And here is another screenshot after updating old TTF fonts from the webcore-fonts package to their latest equivalents from Windows 10. Still no joy in chrome.
,
Nov 12
I can also see that Chromium is engaged in subpixel positioning: I see several image versions for the same glyph. The Firefox does not do that. Hence my question. Are you sure that subpixel positioning in Chrome works correctly?
,
Nov 12
To continue my analysis... So I counted 3 versions of "l" due to subpixel positioning, which is what I would do if I implemented subpixel positioning. Three subpixel positions should magically correspond to simple reading frame shift of RGB triplets. Yet, the actual the actual numbers at the left edge of "l" are as follows: 231 159 71 255 215 135 255 255 199 As you can see this is not a frame shift. In conclusion: Chromium subpixel positioning is broken.
,
Nov 12
@comment 24 Skia/Chromium does subpixel positioning on quarter pixels. Doing a "frame shift of rgb triplets" resulting in third pixel offsets leads to poor color quality when using imperfect gamma correction so we don't do that. Just because you happened to get three 'l' doesn't mean you couldn't have gotten a fourth. So your conclusion is wrong. I'm not sure why you would bring this up either, since it has nothing to do with this issue, which is that Skia is making a different loading / rendering request. This change was done on purpose to try and look like other gtk apps, but apparently there is something else missing.
,
Nov 12
Please disregard my previous post. I counted 4 versions of "t" with the left edge as follows. I think Behdad also told me that this is the granularity of subpixel positioning in Chrome. 175 87 15 55 135 215 231 159 71 15 71 159 255 215 135 47 15 87 175 255 255 255 255 199 111 31 31 In the second line the stem center is right on top of red. In the forth line it is right between green and blue. So the center traveled exactly half a pixel, which is what it should have traveled with 1/4 pixel granularity. Subpixel positioning seems to be working correctly. I would do 1/3pixel steps and simple reading frame shift instead of caching 4 images, but whatever works for you... The only "t" in Firefox goes like this 255 215 135 39 0 79 175 255 255 So it seems to have exact dimensions of the third "t" from Chrome. Why on Earth is it so so much lighter in the center in Chrome????
,
Nov 12
I believe it is because we are now using FT_LOAD_TARGET_LCD instead of FT_LOAD_TARGET_NORMAL in this case. Please see comment #19 including the contents of the linked diff and the Skia issue which is linked from there.
,
Nov 12
Do you know which filter Firefox uses? This is neither default nor light. If Chrome is committed to subpixel positioning than you must do v40 interpreter or autohint light. Despite subpixel positioning the spacing between letters is really much worse in Chrome. What is up with that?
,
Nov 12
Skia is not committed to subpixel positioning, the user can ask for fully hinted non-subpixel positioned aliased rendering if they so choose. The spacing is computed using the shaper (in this case HarfBuzz) and blink may or may not be feeding it the correct metrics in this case. If you wish to make a contribution, please describe what FT_LOAD_TARGET_LCD actually does. Will it always invoke the autohinter, will it sometimes run the v40 interpreter, and will it decide anything based on the font instructions? I'll take a look later myself, but I'm currently working on another issue.
,
Nov 12
Native v40 without horizontal hinting is the default. Autohinter can be forced FT_LOAD_FORCE_AUTOHINT or will take effect if native instructions are missing. FT_LOAD_TARGET_XXX are mostly ignored by native hinters. So unless you force autohinter you will not notice anything. Autohinting is a combination of two *separate* operations: - ADJUST: align stem so that it covers entire pixel, without changing its width. - SNAP: round the stem width to one pixel, without moving its center. MONO does both NORMAL does adjusting LCD does snapping LIGHT does nothing LCD does snapping for historic reasons as a way to reduce color artifacts, before filtering proved more effective. http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/autofit/aflatin.c#n2557 Of course, I only described x-direction and one pixel could be two or three...
,
Nov 12
I was wrong, our documentation is correct LCD == LIGHT, do nothing horizontally. We do not have a mode for snapping only. LCD_V == NORMAL.
,
Nov 12
Skia's current code (see change mentioned in comment 19) now looks a lot like the cairo (and hence gtk) code (see https://github.molgen.mpg.de/git-mirror/cairo/blob/747cab741cf63f30aa6bc2b787fc13e7e7a2b859/src/cairo-ft-font.c#L1874 ). I'll have to take a good look at that to see if it really lines up overall. Note that Chromium will prefer the FontConfig setting to the gtk/xft settings, and will probably take a full restart to pick up new settings (make sure to kill any processes which aren't showing any windows). I would expect changing from 'hintfull' to 'hintmedium' to change something. Oddly enough, it might be that Firefox doesn't look like Chrome here because that build of Firefox has a slightly older Skia in it. I'm curious to know if a nightly build of Firefox looks different on your setup, since it appears that current Firefox source has the change (see https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/gfx/skia/skia/src/ports/SkFontHost_FreeType.cpp#866 ). I'll have to take a look at some other apps in this situation to see how they render. That being said, the character spacing does seem quite bad, which seems surprising since LCD should be light and not change anything horizontally. Perhaps something is being rounded somewhere it shouldn't be.
,
Nov 13
I've taken a look, and can get my 70.0.3538.102 to look very similar in the glyph rendering (but not exact), and my letter spacing is much better (I agree that the letter spacing in the screenshot in comment 33 is pretty bad). It could just be the font difference, but I pulled a newer Arial and that doesn't seem to make a significant difference in any direction. Might need to setup an openSUSE box to reproduce.
,
Nov 14
,
Dec 6
Can somebody check if the subpixel positioning in the context of light autohinter was misled by the error in the FreeType documentation? See this important correction: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=d01e28f41f8810c8ea422b854f8722659589fa99 |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Oct 25