All users were logged out of Bugzilla on October 13th, 2018

Blurry font rendering after update (dev edition)

VERIFIED FIXED in Firefox 41

Status

()

VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: bz, Assigned: jtd)

Tracking

({regression})

41 Branch
mozilla42
Unspecified
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40 unaffected, firefox41 verified, firefox42 verified)

Details

Attachments

(6 attachments)

(Reporter)

Description

3 years ago
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)
(Assignee)

Comment 3

3 years ago
Screenshots are of this page:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5
(Assignee)

Comment 4

3 years ago
Created attachment 8630257 [details]
screenshot, FF38 vs. FF41

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)
(Assignee)

Comment 5

3 years ago
Created attachment 8630260 [details]
screenshot, pango fontgroup vs. fc fontlist, ubuntu 14

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)

Updated

3 years ago
Assignee: nobody → jdaggett
Flags: needinfo?(jdaggett)
(Assignee)

Comment 6

3 years ago
Created attachment 8630280 [details]
testcase, snippet of HTML5 MDN page

Reduced version of HTML5 MDN page that exhibits the problem.
(Assignee)

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 7

3 years ago
Created attachment 8630305 [details]
screenshot, snippet test with the additional use of Open Sans system font
(Assignee)

Comment 8

3 years ago
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.
(Assignee)

Comment 9

3 years ago
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.
(Assignee)

Comment 10

3 years ago
Created attachment 8630848 [details] [diff] [review]
patch, use FcFreeTypeQueryFace to initialize the pattern for downloadable fonts

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)
(Assignee)

Comment 11

3 years ago
Created attachment 8630850 [details]
screenshot, snippet test with patch

Downloaded and system instances of the same font now render identically.
Blocks: 1160510, 1056479
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
Last Resolved: 3 years ago
status-firefox42: --- → fixed
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)
(Reporter)

Comment 16

3 years ago
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.
status-firefox42: fixed → verified
(Assignee)

Comment 18

3 years ago
(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!!
(Assignee)

Updated

3 years ago
See Also: → bug 1171752

Updated

3 years ago
Duplicate of this bug: 1171752
Any plans for uplift this patch to Firefox 41 as it's also affected?
status-firefox40: --- → unaffected
status-firefox41: --- → affected
Flags: needinfo?(jdaggett)
Target Milestone: mozilla42 → mozilla41
(Assignee)

Comment 21

3 years ago
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.