1430430 - Fonts display differently when e10s is ON/OFF using the same fontconfig settings

Status: NEW

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

Description

[tgn-ff]

Attachment: bugzilla_screenshots_and_diffs.tar.gz

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

Steps to reproduce:

A)
1. Close Firefox.
2. Change the fontconfig settings to hinting>full and subpixel>RGB (or the native for your display).
3. Make sure that e10s is enabled; restart if a change was needed.
4. Visit a bug report on bugzilla.mozilla, set Firefox to fullscreen and take a screenshot.

B) Repeat (A), but after disabling e10s.

C) Repeat (A), but after changing fontconfig to hinting>none and subpixel>vBGR (or a non-native for your display).

D) Repeat (C), but with e10s disabled.

I should note that this is not a new issue, and it's happening on both Nightly and Release channels. Droid and Fira fonts are installed on system.


Actual results:

The fonts appear good -to me- only in (B), and they are displayed differently on all steps. Comparing screenshots by eye may be difficult, but if you use GIMP, add two of the screenshots as layers and take their difference, it'll made it obvious. Also, the difference is obvious by eye if you compare the pages directly on Firefox (not screenshots).


Expected results:

There shouldn't be a difference between (A) and (B), and between (C) and (D). Also, the fact that there is a difference between (A) and (C), and between (B) and (D), means that fontconfig settings are not completely disregarded when e10s is enabled.

Also, I tested it on two other sites, one that needed to download the font (https://research.mozilla.org/servo-engines/) and one that used a local font (https://www.reddit.com/r/firefox/ - Arimo), and fonts on both sites displayed as expected.

Comment 1

[Jonathan Kew [:jfkthame]]

Looks like with e10s on, the reporter is getting grayscale antialiasing, while with e10s off, they get subpixel.

Comment 2

[Lee Salzman [:lsalzman]]

Some information from Markus: this appears to be related to usage of BasicCompositor and maybe APZ. When the accelerated OGL compositor is used, the problem goes away and subpixel appears.

<mstange> for a while, we had  a bug where text beyond the viewport would be considered to be over a transparent background, even if it was on an opaque background
<mstange> and it caused subpixel AA to be disabled for that layer
<mstange> I thought that bug was fixed, though

Also possible confirmation that BasicCompositor on other platforms (Mac) has the same issue:
<mstange> I know that it didn't when I was using BasicCompositor a few days ago
<mstange> but with CompositorOGL, I'd expect a component alpha layer there