1645681 - Weird font rendering when hovering on certain site

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Augustin Trancart [:autra]]

Attachment: Peek 12-06-2020 09-27.gif

Description

When hovering certain element on some websites (example: buttons on gitlab.com, tweets on twitter...), there is a weird horizontal displacement of certain letters.

I'm attaching a gif, because it's easier to show it than explain it.

Additional information

I reproduce it on a Lenovo X1 Carbon (cpu: Intel(R) Core(TM) i7-6600U, graphic card Intel Corporation Skylake GT2 [HD Graphics 520]) on a Kubuntu 20.04 both on firefox from apt package (v77) and on Firefox dev edition (v78b6).

I don't reproduce it on a Dell XPS 13 (cpu: Intel Core i7-3537U, graphic card Intel Corporation 3rd Gen (I think it's an HD4000), on a Kubuntu 20.04.

I have no idea which component to select, so selecting "General" :-/

I have opened a bug on launchpad too: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1883369

Please let me know if more informations are needed.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jamie Nicol [:jnicol]]

Thank you for the report! Do you know whether or not you have webrender enabled? Would you please be able to attach a copy of your about:support information?

Do you know whether this has always been the case, or whether it's a recent regression? If it's a regression, if you'd be able to run mozregression to help us track down what caused it, that would be great!

Comment 3

[Augustin Trancart [:autra]]

Attachment: raw about:support

Comment 4

[Augustin Trancart [:autra]]

Thanks for your answer.

Do you know whether this has always been the case, or whether it's a recent regression?

I think it happens when I upgraded my ubuntu from 19.10 to 20.04

I have gfx.webrender.enabled to false.

if you'd be able to run mozregression to help us track down what caused it, that would be great!

well I'd like to, but every time mozregression starts a firefox, all the tabs always crash... I cannot load a single website :-(

Comment 5

[Augustin Trancart [:autra]]

In the meantime, I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1645969 for my mozregression problem.

Comment 6

[Jamie Nicol [:jnicol]]

Thanks for filing the mozregression issue. I'm afraid I can't help with it but hopefully somebody can on that bug.

In the meantime, could you try setting layers.acceleration.force-enabled=true in about:config, restart firefox, and see if it reproduces. Then after that, try setting gfx.webrender.all=true, restart, and see if it reproduces.

Comment 7

[dennis]

I have the same problem. For me layers.acceleration.force-enabled=true solves this font problem, but generates another. Now in all menus, the mouseover/hover highlighting/selection of the menus is sometimes not shown (For example: Right click on the website, move your mouse over the menu items. The highlighting does not always follow the mouse and gets stuck in previous items)
Additionally using gfx.webrender.all=true doesn't solve that problem. But I prefer this problem over the strange fonts in websites.

Comment 8

[Augustin Trancart [:autra]]

layers.acceleration.force-enabled=true

this fixes the issue.

gfx.webrender.all=true

this also fixes the issue.

So : I reproduce the issue if and only if both are false.

Additionally I don't reproduce on nightly, with both variables set to false.

Comment 9

[Jamie Nicol [:jnicol]]

(In reply to Augustin Trancart [:autra] from comment #8)

Additionally I don't reproduce on nightly, with both variables set to false.

This might be because on nightly webrender is enabled by default even if this pref is false. You could check this in about:support.

It seems like it's probably a text painting issue which only occurs on basic layers then. Lee, any idea what could be going on?

Comment 10

[Lee Salzman [:lsalzman]]

Jonathan, seems vaguely like a layout issue? I think we have seen issues in the path where depending on how the CSS of the site was doing things for onhover (potentially animation/will-change related), it could route through different AA/hinting settings somehow?

Comment 11

[Jonathan Kew [:jfkthame]]

Yeah, it looks like during the transition between hover/non-hover states, the glyphs are switching from subpixel-AA to grayscale, then back again; and while they're in the non-subpixel state, their spacing is terrible -- like maybe they've been individually rounded to pixels, without actually re-doing the layout to account for pixel rounding (which would re-calculate spacing everywhere, potentially changing line breaks, etc., so that would come with its own issues).

I don't know what the twitter code (for example) is doing that triggers this, but it seems likely something to do with running an animation/transition that causes the layerization to change while it's active. IIRC there are various conditions that force subpixel-AA to be disabled, and presumably one (or more) is involved here.

The main problem, though, is the incorrect pixel-snapping of the glyph positions when we're in the grayscale-render state. If we were just painting the glyphs in grayscale, without any change to their positions, the effect would be much less troubling; the quality of the AA would temporarily degrade during the transition, so the text would look a bit less clear, but it wouldn't jiggle about in such a horrible way.

Not currently sure exactly what level this is happening at, though... or how easy it'll be to reproduce and catch it for closer examination. Given that the reporter says "I think it happens when I upgraded my ubuntu from 19.10 to 20.04", local font rendering settings (freetype prefs etc) may be part of the formula, as well as whatever the sites are doing in their css/js.

Comment 12

[dennis]

I found the ugly rendering is also persistent (not just on hover) on some websites, and doesn't completely go away when setting the two about:config options. For me it is always there in the google mail interface (however, not the displayed mail content).

Here, it started after an ubuntu 18.04 to 20.04 upgrade.

It goes away if I uncheck "Allow pages to choose their own fonts, instead of your selections above" in the Firefox font settings, but then the integrated PDF viewer is not able to show most documents: Fonts are just entirely gone and you see documents with mostly blank pages (not sure if that is expected or a related / different bug).

Comment 13

[Augustin Trancart [:autra]]

I found the ugly rendering is also persistent (not just on hover) on some websites

Yes, one of those websites is the demo version of codimd (https://demo.codimd.org, in the preview pane). It is not always bad though, but it eventually gets there, and then it stays ugly.

local font rendering settings (freetype prefs etc) may be part of the formula, as well as whatever the sites are doing in their css/js.

I can test some other local settings if you want.

Comment 14

[Lee Salzman [:lsalzman]]

(In reply to Augustin Trancart [:autra] from comment #13)

I found the ugly rendering is also persistent (not just on hover) on some websites

Yes, one of those websites is the demo version of codimd (https://demo.codimd.org, in the preview pane). It is not always bad though, but it eventually gets there, and then it stays ugly.

local font rendering settings (freetype prefs etc) may be part of the formula, as well as whatever the sites are doing in their css/js.

I can test some other local settings if you want.

Do you use hintfull in your fontconfig hintstyle settings? It might be that when it is rendering with subpixel AA it uses the LCD-hinting algorithm, whereas when it goes to grayscale it has to use the normal hinting algorithm. If so, if you try using some other hintstyle like hintslight explicitly in your fontconfig settings, does it fix it?

Comment 15

[Augustin Trancart [:autra]]

Do you use hintfull in your fontconfig hintstyle settings?

No. I have a powerline config in my fontconfig conf directory though, which contains

 <match target="font">
  <edit name="hinting" mode="assign">
   <bool>false</bool>
  </edit>
 </match>
 <match target="font">
  <edit name="hintstyle" mode="assign">
   <const>hintnone</const>
  </edit>
 </match>
 <match target="font">
  <edit name="rgba" mode="assign">
   <const>bgr</const>
  </edit>
 </match>
 <match target="font">
  <edit name="antialias" mode="assign">
   <bool>true</bool>
  </edit>
 </match>

I'm attaching the full file just in case, and I'm going to test stuff with it.

Comment 16

[Augustin Trancart [:autra]]

Attachment: 10-powerline-symbols.conf in ~/.config/fontconfig/conf.d

Comment 17

[Augustin Trancart [:autra]]

(In reply to Lee Salzman [:lsalzman] from comment #14)

(In reply to Augustin Trancart [:autra] from comment #13)

I found the ugly rendering is also persistent (not just on hover) on some websites

Yes, one of those websites is the demo version of codimd (https://demo.codimd.org, in the preview pane). It is not always bad though, but it eventually gets there, and then it stays ugly.

local font rendering settings (freetype prefs etc) may be part of the formula, as well as whatever the sites are doing in their css/js.

I can test some other local settings if you want.

Do you use hintfull in your fontconfig hintstyle settings? It might be that when it is rendering with subpixel AA it uses the LCD-hinting algorithm, whereas when it goes to grayscale it has to use the normal hinting algorithm. If so, if you try using some other hintstyle like hintslight explicitly in your fontconfig settings, does it fix it?

Ok so thanks to your message, I have be able to dig into this a bit. By default I use hintslight (10-hinting-slight.conf is linked into my /etc/fonts/conf.d), but the font that bugs is Roboto, that has its own config file in /etc/fonts/conf.d, and it uses hintfull. So I've edited this file directly, and every other value stops the jittering for me (it does not stop some weird spacing though, for instance sometimes the "i" is to close one of its sibling).

So I'm wondering: what is the correct fix here? Is this a config bug and I should raise the issue to the fontconfig package mainteneur? A font issue? Or a firefox one?

Comment 18

[Lee Salzman [:lsalzman]]

Really we'd want to avoid this transition from subpixel AA to grayscale on our side in the first place. But looking back, if you were using hintnone, this might have been fixed recently by bug 1732577. Worth a try in nightly to see if this is still a problem.