1589888 - The font SubPixel are colored in Gray if the text color has transparency and exists a symbol like 🌷

Status: RESOLVED FIXED

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

Description

[Andronachi Marian]

Attachment: SubPixel.avi

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763

Steps to reproduce:

I read a comments from a YouTube video and I see some font are blurry.
After I see more deep the SubPixels are colored with Gray.

This is happening in Dark Theme and the color has transparency.

Comment 1

[Andronachi Marian]

PS:
Or if i remove the chars like: 😭, 😂, etc; from the text works fine with the color transparency.

But if i have a color transparency and a symbol is not working.

The video is if need: https://www.youtube.com/watch?v=9RbnBF0B58Y

Comment 2

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

The priority flag is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Lee Salzman [:lsalzman]]

Can you please include screenshots that clearly show the problem, and a clearer description of what the problem is in them? I am having trouble understanding what is going on.

Comment 4

[Andronachi Marian]

Attachment: Figures.PNG

I don't know how to explain more tehnical. This may help what i mean: https://en.wikipedia.org/wiki/Font_rasterization

Problem:

The problem is that if the font color has transparency and an utf-8 character, the font subpixels are colored with gray. See in Figures.png [Fig_0]

Expected:

The subpixels need to be colored with RGB like others: Figures.png [Fig_1]

Comment 5

[Andronachi Marian]

You see the difference if you use the Magnifier or PrintScreen the screen and zoom to text.
I made a simple text to see: https://jsfiddle.net/AndRo_Marian/52by9q3z/

Comment 6

[Lee Salzman [:lsalzman]]

Jonathan, any idea why subpixel gets disabled here for the entire span when the emoji is present?

Comment 7

[Jonathan Kew [:jfkthame]]

I guess the emoji character is causing fallback to a different font than the Latin-script text; that font is (understandably) a color font that causes HasSyntheticBoldOrColor to return true at https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/gfx/thebes/gfxTextRun.cpp#586; and this makes us take a different rendering path for the whole textrun.

Maybe we should be doing that check at a lower level, so that only the specific glyphRun using the emoji font goes through this path; not sure offhand how complex it might be to make that decision per-glyph-run rather than per-text-run.

(The other conditions being tested there -- drawMode, partial-opacity -- would be things that apply to the whole textrun, so it's preferable to make the decision at this level, but the synthetic-bold or color-font question is specific to the individual font used by each glyph run.)

Comment 8

[Jonathan Kew [:jfkthame]]

FWIW, I can reproduce this on macOS as well, although the difference is hard to notice on a retina screen. Also, I notice that it does not reproduce with WebRender enabled.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1589888 - Handle glyph buffering for color or synthetic-bold fonts with partial opacity on a per-glyphrun basis. r=lsalzman

Comment 10

[Jonathan Kew [:jfkthame]]

I think something like this ought to help. I've just pushed a try run to see if it breaks any reftests... https://treeherder.mozilla.org/#/jobs?repo=try&revision=147aed9dceecfe3074a7c092af4753182a039aba.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7071b1bdd741
Handle glyph buffering for color or synthetic-bold fonts with partial opacity on a per-glyphrun basis. r=lsalzman

Comment 12

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/7071b1bdd741