Closed Bug 981627 Opened 6 years ago Closed 6 years ago

Lots of text rendered as white instead of black in recent nightlies

Categories

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

x86_64
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox29 --- unaffected
firefox30 + fixed
firefox31 --- verified

People

(Reporter: catlee, Assigned: jfkthame)

References

Details

Attachments

(1 file)

I just updated to today's nightly and was presented with a browser that looked like this:
http://people.mozilla.org/~catlee/sattap/7ea0fee3.png
http://people.mozilla.org/~catlee/sattap/d0190efe.png

The best regression range I can come up with so far is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0e7f63c2138&tochange=d01bf8596d3b

This doesn't seem to happen with new profiles, so it's possible there's something in my profile causing this to happen.
Weird. It's possible the freetype/color-glyphs stuff from bug 974575 is somehow related to this, but I'm not sure. If you can determine what setting in your profile is triggering it, that would be helpful.
I've updated Nightly on my Ubuntu64 VM to today's build, but am not seeing this issue there.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> Weird. It's possible the freetype/color-glyphs stuff from bug 974575 is
> somehow related to this, but I'm not sure. If you can determine what setting
> in your profile is triggering it, that would be helpful.

I'm not sure how to go about doing that. Any pointers?
Maybe look at what about:support lists by way of extensions, modified prefs, etc., and start applying the same settings to a new (trouble-free) profile until the problem reappears.
I have gfx.xrender.enabled = false in prefs.js. If I disable this then text is rendered correctly.
I'm seeing the same thing when I run Firefox builds under VNC.  I confirmed that my problem matches the regression range in comment 0 (m-c nightlies) though I didn't check the narrower range in comment 1.
glyph_surface->format is CAIRO_FORMAT_ARGB32; if I make it take the first branch, things work again.
Hmm. Yes, that would presumably fix it, as it effectively returns to the pre-patch codepath. However, it will break the rendering of color fonts, IIUC.

So the trouble arises from the unexpected occurrence of glyphs with surface-format ARGB32; I thought that would only be used for actual color glyphs, but apparently in some configurations it's happening for normal monochrome/outline fonts. (I wonder why?)

I guess we probably need to find another way to distinguish actual color glyphs from the alpha masks created for antialiased outline glyphs.
David and/or Chris, could you confirm whether this patch resolves the problem for you? Thanks.
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8394723 - Flags: feedback?(dbaron)
Attachment #8394723 - Flags: feedback?(catlee)
Comment on attachment 8394723 [details] [diff] [review]
glyph surface with ARGB format might not be a true color glyph

This fixes the problem I'm seeing (in a VNC server).
Attachment #8394723 - Flags: feedback?(dbaron) → feedback+
Attachment #8394723 - Flags: feedback?(catlee) → review?(jmuizelaar)
Comment on attachment 8394723 [details] [diff] [review]
glyph surface with ARGB format might not be a true color glyph

Review of attachment 8394723 [details] [diff] [review]:
-----------------------------------------------------------------

Does this need upstreaming and can you do it?
Attachment #8394723 - Flags: review?(jmuizelaar) → review+
(In reply to Jeff Muizelaar [:jrmuizel] from comment #13)
> Comment on attachment 8394723 [details] [diff] [review]
> glyph surface with ARGB format might not be a true color glyph
> 
> Review of attachment 8394723 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Does this need upstreaming and can you do it?

I don't think so - it looks like current upstream cairo-image-surface.c is substantially changed from what we have in our tree, and as yet this part of the color-glyph support from bug 974575 hasn't been ported there.

cc'ing Behdad on this bug just to bring it to his notice, but I suspect the eventual upstream solution will end up looking different anyhow.
Blocks: 974575
We should uplift the fix to FF30 once it is safely on Nightly and confirmed to resolve the problem, as this is a bad regression for Linux users with an affected configuration. (Though it's not clear to me how common that may be.)
My bad.  Let me fix today.
Ok, the patch that went into Firefox is a rework of my WIP patch on cairo.  In short, instead of these two lines:


    1.45 +	    if (glyph_surface->format == CAIRO_FORMAT_A8 ||
    1.46 +	        glyph_surface->format == CAIRO_FORMAT_A1)

You need:

+           if (glyph_surface->format != CAIRO_FORMAT_ARGB32 ||
+               pixman_image_get_component_alpha (glyph_surface->pixman_image))

The rationale is: ARGB glyphs are used for subpixel rendering, but those have component_alpha set to true.
https://hg.mozilla.org/mozilla-central/rev/0015731e2e29
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Can we get an uplift nomination here for Aurora?
Flags: needinfo?(jfkthame)
Comment on attachment 8394723 [details] [diff] [review]
glyph surface with ARGB format might not be a true color glyph

[Approval Request Comment]
Bug caused by (feature/regressing bug #): support for color glyphs (bug 974575)

User impact if declined: some Linux users (depending on system configuration) get white text instead of black for normal text

Testing completed (on m-c, etc.): on m-c for a couple weeks

Risk to taking this patch (and alternatives if risky): minimal risk, just restores an old codepath in an additional case

String or IDL/UUID changes made by this patch: none
Attachment #8394723 - Flags: approval-mozilla-aurora?
Flags: needinfo?(jfkthame)
Attachment #8394723 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: in-testsuite?
Keywords: verifyme
Reproduced on Nightly 2014-03-10 with gfx.xrender.enabled = false in about:config - not all text is properly displayed. With the same profile, text renders fine using Firefox 31 beta 4.

Is this test enough to mark this bug as verified? Thank you
Flags: needinfo?(jfkthame)
I think so - thanks.
Status: RESOLVED → VERIFIED
Flags: needinfo?(jfkthame)
Removing the keyword based on above comments.
You need to log in before you can comment on or make changes to this bug.