Open Bug 1406694 Opened 7 years ago Updated 2 years ago

font rendering become too dark / bold @FF56

Categories

(Core :: Graphics: Text, defect, P2)

56 Branch
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox56 + wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: a29988122, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Update from FF55 to FF56


Actual results:

https://imgur.com/a/uOMLo

Please download the original file, and you can clearly see that the text in one pic is slightly "darker, deeper, bolder" than the other one.


Expected results:

The text color should stay the same in FF55, since it's not beautiful in the FF56 version.

By the way, I tried a whole new install of FF55 and FF56 inside VM, and the results stays the same.
Component: Untriaged → Layout: Text
Product: Firefox → Core
I think this belongs in Graphics rather than Layout. Looking at the screenshots, they appear to be exactly the same font, but a difference in rendering -- perhaps a change in the gamma value, or some other issue affecting how the glyphs are rasterizer or composited to the output. It looks like both screenshots show a similar antialiasing mode (cleartype/subpixel-AA in both cases), but there's a definite difference in darkness or intensity.
Component: Layout: Text → Graphics: Text
Sounds like a recent regression in 56. 


Andrei, can your team take a look to confirm the issue?
Flags: needinfo?(andrei.vaida)
Let's see where the regression range gets us.
Priority: -- → P2
Whiteboard: [gfx-noted]
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Tested this issue on Windows 10 x64 with the STR from the description( Update from 55.0.3 Build ID:20170824053622 to 56.0)with the default theme and with Compact Light theme and on the latest Nightly 58.0a1 (2017-10-26) and could not reproduce it. 

@a29988122, please troubleshoot with Safe Mode: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode.
Also please provide the contents of the about:support page.
What theme do you use? After the update, you open FF 56 with the same profile?
Flags: needinfo?(andrei.vaida) → needinfo?(a29988122)
I'll answer your questions first:
1. Default theme all the time.
2. I tested both my daily profile and a whole new profile. They both yielded the same result.

==
Okay, please let me explain my test methodology.
Check the following link, which contained about:supprot info and screenshot pngs.
https://www.dropbox.com/s/e588f7u1rbxm98b/firefox.rar?dl=0

I tried nearly all of the combinations of the following conditions, screenshot each one, and then use gimp to grab the color of "the shadow of the red t alphabet"(the top left most test123 word's t), zoom to max and you'll find out that the rightmost pixel of the alphabet t has a shadow consists of single color. I use that color as a compare basepoint.

Condition combinations:
FF55, FF56
safemode, normal mode addon all enable, normal mode addon all disable
my daily profile, a whole new profile

And you can check the filenames to understand my test results.
On my PC(amd graphics, windows 10), all the safemode has the same rendering color which is e3c6ff, regardless of Firefox version.
Also, whether addons was enabled or disabled, it did not affect the results.

The result is consistent: ff55:e2b8ff, ff56:e0a1ff, safemode:e3c6ff.

I suggest you check the contained info.txt for further info - it's likely hardware related.
Although I did not test it on VM today, I have strong confidence that it will yield the same result(since that's what I did last time)
Flags: needinfo?(a29988122)
Tested again on Windows 10 x64 ( ATI Radeon 3000 Graphics) and on Windows 10 x64 (AMD HD 5450 graphics) using the STR from comment 5. Here are the results:
- new profile :55.0.3:E18FB5 vs 56.0:E18FB5
- safe mode :  55.0.3:E28EBA vs 56.0:E28EBA

Since you can't reproduce this bug in safe mode it would be really helpful if you find a regression range using mozregression:
http://mozilla.github.io/mozregression/

My guess is that on Nightly 2017-03-10 (https://archive.mozilla.org/pub/firefox/nightly/2017/03/2017-03-10-03-02-05-mozilla-central/) the bug should not be reproducible so you could try with this one as good build in mozregression.

Thanks.
Flags: needinfo?(a29988122)
Sorry for the late reply. Got some real life(TM) issue.

https://imgur.com/a/d1fKA

I guess this is what we need - By using the regression tool, I finished the binary search of commit(s)?
:P Great tool by the way! Really handy and useful.

All the speculations are still followed by the methodology described earlier. The results are consistent.
==
2017-11-09T18:54:42: DEBUG : Found commit message:
Bug 1383817 - clamp gamma/contrast for ScaledFontDWrite when creating SkTypeface. r=mchang

The first error build is 02a51905
and the last OK build is 64bdbc8e
===

By doing this bug report, It greatly inspired, encouraged me as a CS student, I'd really like to keep it going till the end of the issue being resolved. 

Thank you!
Flags: needinfo?(a29988122) → needinfo?(roxana.leitan)
(In reply to a29988122 from comment #7)
> Sorry for the late reply. Got some real life(TM) issue.
> 
> https://imgur.com/a/d1fKA
> 
> I guess this is what we need - By using the regression tool, I finished the
> binary search of commit(s)?
> :P Great tool by the way! Really handy and useful.
> 
> All the speculations are still followed by the methodology described
> earlier. The results are consistent.
> ==
> 2017-11-09T18:54:42: DEBUG : Found commit message:
> Bug 1383817 - clamp gamma/contrast for ScaledFontDWrite when creating
> SkTypeface. r=mchang
> 

Lee, could you please take a look?
Blocks: 1383817
Flags: needinfo?(roxana.leitan) → needinfo?(lsalzman)
Did you alter the operating system gamma and/or contrast values, and if so, to what?
Flags: needinfo?(lsalzman) → needinfo?(a29988122)
Part of the issue appears to be that when using the Skia content backend, in version 55, due to a bug, we didn't actually properly respect the contrast settings at all. In your settings, you have ClearType Enhanced Contrast amped up to 300. In 56, we are actually using the setting, so you're getting some reasonable interpretation of the contrast level you requested.

The only thing I may still need to look into is whether or not the Skia interpretation of that contrast level matches the Direct2D interpretation.

For now, I would recommend turning down the OS Enhanced Contrast setting until I have a chance to verify.
I looked into this more deeply. Essentially, the level of contrast you are getting for a given setting in Skia is a relatively good match for what we're getting in the Direct2D backend.

So, I am going to agree with my previous assessment, that the lighter text you were seeing before was due to a bug in how we parsed contrast settings from the OS.

An easy way to fix this is via a pref: gfx.font_rendering.cleartype_params.enhanced_contrast

The default value of that is 100, and can go as low as 0. Try setting it to a value like 0 or 50 to get a more reasonable contrast setting.

Since you have it set to 300 in the OS (which we clamp down to 100), it is using some fairly maximal contrast under the circumstances.
(In reply to Lee Salzman [:lsalzman] from comment #11)
> I looked into this more deeply. Essentially, the level of contrast you are
> getting for a given setting in Skia is a relatively good match for what
> we're getting in the Direct2D backend.
> 
> So, I am going to agree with my previous assessment, that the lighter text
> you were seeing before was due to a bug in how we parsed contrast settings
> from the OS.
> 
> An easy way to fix this is via a pref:
> gfx.font_rendering.cleartype_params.enhanced_contrast
> 
> The default value of that is 100, and can go as low as 0. Try setting it to
> a value like 0 or 50 to get a more reasonable contrast setting.
> 
> Since you have it set to 300 in the OS (which we clamp down to 100), it is
> using some fairly maximal contrast under the circumstances.

It's fascinating to know that it's rather a *bugfix* than a *new bug*!
Thank you for tracing this with me.

In windows 10, I was able to change EnhancedContrastLevel to 150(not the default value 100! no idea why.), gfx.font_rendering.cleartype_params.enhanced_contrast to 100(default I guess) to achieve the same contrast as in previous version (e2b8ff).

Dunno if "respect system cleartype settings" is a good behavior, since it existed so long that it might as well be a *intended behavior* to some - I guess many might felt as confused as I did if they tweaked cleartype setting heavily.

==
-Just amateur opinion-
I considered when migrate a profile to a new OS, they should stay the same (in the most ideal situation), rather than ..uhh, affected heavily by the new os?
==

Anyway good luck to the FF57 update! Although most of my addons would become obsolete, I still believe that it could bring a fresh new air into FF.
Flags: needinfo?(a29988122)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.