Closed Bug 1170688 Opened 5 years ago Closed 5 years ago

Text rgba alpha ignored for synthetic bold text

Categories

(Core :: Graphics: Text, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
p11 + ---
firefox41 --- fixed
fennec + ---

People

(Reporter: miketaylr, Assigned: birtles)

References

()

Details

(Keywords: regression, Whiteboard: [see comment 12 for affected platforms], [gfx-noted])

Attachments

(4 files, 1 obsolete file)

Attached file text-shadow-alpha.html
If you open the attached test case (also available at http://output.jsbin.com/tugiraquhi), compare the rendering of the Japanese text and the English text.

Expected: Very faint text-shadow on both.
Actual: Solid text-shadow on Japanese text.
This works as expected on OSX.
tracking-fennec: --- → ?
tracking-p11: --- → ?
Version: unspecified → Trunk
Digging into this a little bit I notice:

* This works fine on Firefox OS
* The font being used for the Japanese glyphs is 'MotoyaLMaru W3 mono'
* It is only the alpha channel being ignored (I can change the color of the shadow)
* The alpha channel is basically being ceiled to 1 (so 0->0, 0.01 -> 1)
* If I make the string 'あa' both glyphs show the problem--i.e. even the Latin 'a' ignores the alpha despite using a different font
It also only happens when the blur radius is 0.
This is going to take quite a while before I've got an Android debug build environment up and running due to lack of disk space but so far I can see:

* This isn't about text-shadow, but applies to text alpha in general if you set, e.g. color: rgba(100, 100, 200, 0.5);
* It only appears when we set font: bold

It may be related to doing synthetic bolding since we handle that differently in gfxTextRun::Draw.

At a guess, there may be some odd font metrics in the Motoya fonts that cause us to get the size of the synthetic bold buffer wrong? I tried reproducing this on desktop using the same font but didn't succeed. Perhaps I'm using a newer version of the font, perhaps text-inflation is causing differences on Android, or perhaps there are platform-specific differences here I'm not aware of.

FWIW, the version of the Motoya fonts I'm trying is here:

https://github.com/android/platform_frameworks_base/blob/master/data/fonts/MTLmr3m.ttf
Summary: text-shadow rgba alpha ignored for Japanese text → Text rgba alpha ignored for synthetic bold Japanese text
Narrowing this down a bit further I see the same bug when simply using a font without a bold variant.

  http://jsfiddle.net/gxmhhskj/

Seems like we're not applying the alpha for synthetic bold on Android correctly. Works fine for me on Firefox OS, Windows, and Linux.
Summary: Text rgba alpha ignored for synthetic bold Japanese text → Text rgba alpha ignored for synthetic bold text on Android
(In reply to Brian Birtles (:birtles) from comment #6)
> Works fine for me on Firefox OS, Windows, and Linux.

I forgot to mention, for Windows and Linux I tested nightly but for Firefox OS I only tested Firefox OS 2.0. I'll check a more recent build of Firefox OS.
I can see this bug in a more recent Firefox OS build (apparently based on Gecko 41 although I don't remember flashing the device that recently) but not on Firefox OS 2.0 based on Gecko 32.
Potentially related enhancement:
https://bugzilla.mozilla.org/show_bug.cgi?id=1173221

It may be that one simple way to fix this would be to use the FreeType embolden feature to solve this problem. That's a better way to synthetically bold than using the generic "stamp" method.
Since I can repro this on Firefox OS it should be easier to debug.
Summary: Text rgba alpha ignored for synthetic bold text on Android → Text rgba alpha ignored for synthetic bold text on Android and Firefox OS
The bug will occur on any platform where mApplySyntheticBold is used to enable synthetic bolding - OSX, Android, FFOS, GDI.
Just a guess but I suspect this happened when the gfxFont::Draw code was refactored in bug 1037340.
Component: Graphics, Panning and Zooming → Graphics: Text
Product: Firefox for Android → Core
Summary: Text rgba alpha ignored for synthetic bold text on Android and Firefox OS → Text rgba alpha ignored for synthetic bold text
Whiteboard: [see comment 12 for affected platforms]
Whiteboard: [see comment 12 for affected platforms] → [see comment 12 for affected platforms], [gfx-noted]
You can reproduce this on Windows by turning off Hardware Acceleration (under Preferences -> General). 
With Hardware acceleration on, the two lines in test case in attachment 8617729 [details] are DIFFERENT (the second one is translucent).
With Hardware acceleration off, the two lines are the SAME.
(In reply to Brian Birtles (:birtles) from comment #14)
> You can reproduce this on Windows by turning off Hardware Acceleration
> (under Preferences -> General). 

Sorry, Preferences -> Advanced (requires restart).
Thanks Alice!
Assignee: nobody → jfkthame
tracking-fennec: ? → +
Turns out the bug is in part 2 of bug 1037340. Seems we have an old gfxContext. If we pass the gfxContext around instead of relying on the one in the params struct the bug goes away.
Assignee: jfkthame → bbirtles
Status: NEW → ASSIGNED
This fixes a regression when painting semi-transparent synthetic bold text. When
we do that we update the draw target but refactoring in bug 1037340 part
2 caused us to store the draw target before it was updated.
Attachment #8624593 - Flags: review?(jfkthame)
I'm still trying to work out a simple regression test for this. Any ideas appreciated.
Attachment #8624593 - Flags: review?(jfkthame) → review+
Thanks for the fix!

Seems like you could at least have a != reftest based on the second testcase here, I think?
(In reply to Jonathan Kew (:jfkthame) from comment #21)
> Thanks for the fix!
> 
> Seems like you could at least have a != reftest based on the second testcase
> here, I think?

Yes, I think so. Thanks!
Whiteboard: [see comment 12 for affected platforms], [gfx-noted] → [see comment 12 for affected platforms], [gfx-noted], [leave-open]
Attachment #8626557 - Flags: review?(jfkthame)
Comment on attachment 8626557 [details] [diff] [review]
part 2 - Add test for text alpha on synthetic bold

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

::: layout/reftests/text/1170688.html
@@ +7,5 @@
> +  font-family: Calibri, Verdana, sans-serif;
> +}
> +@font-face {
> +  font-family: local-arial;
> +  src: local(ArialMT), local(Arial);

I'd suggest using one of the fonts we have in the tree for test purposes, such as

  src: url(../fonts/sil/GenR102.ttf);

so that we can be sure we're using our single-weight family on all platforms.

(The test will also need HTTP(..) in the manifest to enable this.)
Attachment #8626557 - Attachment is obsolete: true
Attachment #8626557 - Flags: review?(jfkthame)
Attachment #8626807 - Flags: review?(jfkthame) → review+
Whiteboard: [see comment 12 for affected platforms], [gfx-noted], [leave-open] → [see comment 12 for affected platforms], [gfx-noted]
https://hg.mozilla.org/mozilla-central/rev/1e7d5ce4c80f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.