Closed Bug 1180415 Opened 9 years ago Closed 9 years ago

Blurry font rendering after update (dev edition)

Categories

(Core :: Graphics: Text, defect)

41 Branch
Unspecified
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla42
Tracking Status
firefox40 --- unaffected
firefox41 --- verified
firefox42 --- verified

People

(Reporter: bz, Assigned: jtd)

References

Details

(Keywords: regression)

Attachments

(6 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150704004007

Steps to reproduce:

* Visited https://developer.mozilla.org/en-US/docs/Web/HTML/Element/cite
* Observed the rendered page
* Took a screenshot of the page using GIMP


Actual results:

Text was rather blurry/not as sharp as before.

Screenshot: https://i.imgur.com/CJB7Mf1.png


Expected results:

Text rendered sharply as in previous Firefox versions.

Screenshot from Firefox version 38 (non developer edition): https://i.imgur.com/MBm6tzG.png
I don't know enough about Linux font rendering to help here properly...  Jonathan, would you be able to route this in the right direction?
Component: Untriaged → Graphics: Text
Flags: needinfo?(jfkthame)
OS: Unspecified → Linux
Product: Firefox → Core
The screenshots show the same font, and both have subpixel antialiasing. But it looks like we may be getting a subtly different antialiasing or hinting mode. Possibly related to the Linux platform font list changes; ni'ing jdaggett to look into this. (Are we failing to respect fontconfig settings in the same way as before?)
Flags: needinfo?(jfkthame) → needinfo?(jdaggett)
Side-by-side rendering of the two linked screenshots, FF38 on the left, FF41 on the right. As Jonathan notes, it's clearly not a font selection problem but some subtle rendering issue.

Could I ask you to run a quick test? Using FF41, could you post screenshots of the testpage with and without 'gfx.font_rendering.fontconfig.fontlist.enabled' set to true? Setting it to 'false' will use the old font backend, so that will tell us if the problem is related to the new font backend. You'll need to restart after flipping that pref.

The only other thing I can think of is that this might somehow be WOFF2 related but it looks like we're always serving woff files.
Flags: needinfo?(bz)
Never mind, I can reproduce this by flipping the pref on my local Ubuntu install.

Left is with the pref set to 'false', which uses the gfxPangoFontGroup code, and the right with it set to 'true', the default for nightly/dev channels.
Flags: needinfo?(bz)
Assignee: nobody → jdaggett
Flags: needinfo?(jdaggett)
Reduced version of HTML5 MDN page that exhibits the problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 8630305 [details]
screenshot, snippet test with the additional use of Open Sans system font

Screenshot shows that Open Sans loaded as a webfont is rendering differently from the same font loaded as a system font, so I'm guessing the problem is in the code used to initialize the pattern for downloadable fonts. Same test with the pango fontgroup code renders the same for the two lower paragraphs.
When creating downloadable fonts, the current fontconfig platform fontlist code uses an empty pattern, which effectively disables hinting. Solution is to mimic the existing pango fontgroup code and initialize the pattern from the FTFace via FcFreeTypeQueryFace. This enables hinting correctly.
Mimic the existing pango fontgroup code, using FcFreeTypeQueryFace to initialize the pattern for downloadable fonts. I'm assuming we can rely on FcFreeTypeQueryFace always being available at this point.
Attachment #8630848 - Flags: review?(karlt)
Downloaded and system instances of the same font now render identically.
Comment on attachment 8630848 [details] [diff] [review]
patch, use FcFreeTypeQueryFace to initialize the pattern for downloadable fonts

r+ with null return value handling added and the comments from
gfxDownloadedFcFontEntry::InitPattern() re the file and blanks arguments
copied.
Attachment #8630848 - Flags: review?(karlt) → review+
https://hg.mozilla.org/mozilla-central/rev/f4ab476a4cb9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
@lol768 this should be fixed in tomorrow's Nightly build on https://nightly.mozilla.org/. Can you please check it and report back your results? Thanks.
Flags: needinfo?(bz)
Just tried https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5 (apologies for getting the URL wrong in the original report) in Nightly v42.0a1 (2015-07-09) and the text looks great and is no longer blurry as it was with the developer edition. The problem's fixed.

Thanks.
Flags: needinfo?(bz)
Status: RESOLVED → VERIFIED
Thank you lol768.
(In reply to lol768 from comment #16)
> Just tried https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5
> (apologies for getting the URL wrong in the original report) in Nightly
> v42.0a1 (2015-07-09) and the text looks great and is no longer blurry as it
> was with the developer edition. The problem's fixed.
> 
> Thanks.

Thanks for taking the time to report this!!
See Also: → 1171752
Any plans for uplift this patch to Firefox 41 as it's also affected?
Flags: needinfo?(jdaggett)
Target Milestone: mozilla42 → mozilla41
Comment on attachment 8630848 [details] [diff] [review]
patch, use FcFreeTypeQueryFace to initialize the pattern for downloadable fonts

Approval Request Comment
[Feature/regressing bug #]: 1056479
[User impact if declined]: downloadable fonts will not be hinted properly
[Describe test coverage new/current, TreeHerder]: no problems reported
[Risks and why]: this is a minor fix with a big impact on readability of downloaded fonts
[String/UUID change made/needed]: none
Flags: needinfo?(jdaggett)
Attachment #8630848 - Flags: approval-mozilla-aurora?
Comment on attachment 8630848 [details] [diff] [review]
patch, use FcFreeTypeQueryFace to initialize the pattern for downloadable fonts

Approving for uplift, this was verified to work on 07-9 nightly.
Attachment #8630848 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Virtual_ManPL [:Virtual] from comment #20)
> Any plans for uplift this patch to Firefox 41 as it's also affected?

Target milestone tracks when a patch lands on mozilla-central. Please don't randomly change it based on what other releases it happens to affect as it negatively affects the process of getting patches uplifted.
Target Milestone: mozilla41 → mozilla42
Flags: needinfo?(bernesb)
Sorry, it wasn't intended, I probably miss-clicked this as "Version".
Flags: needinfo?(bernesb)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: