Closed
Bug 1170688
Opened 7 years ago
Closed 7 years ago
Text rgba alpha ignored for synthetic bold text
Categories
(Core :: Graphics: Text, defect)
Core
Graphics: Text
Tracking
()
RESOLVED
FIXED
mozilla41
People
(Reporter: miketaylr, Assigned: birtles)
References
()
Details
(Keywords: regression, Whiteboard: [see comment 12 for affected platforms], [gfx-noted])
Attachments
(4 files, 1 obsolete file)
471 bytes,
text/html
|
Details | |
720 bytes,
text/html
|
Details | |
3.62 KB,
patch
|
jfkthame
:
review+
|
Details | Diff | Splinter Review |
2.24 KB,
patch
|
jfkthame
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•7 years ago
|
||
Originally reported at https://github.com/webcompat/web-bugs/issues/1142.
Reporter | ||
Comment 2•7 years ago
|
||
This works as expected on OSX.
Reporter | ||
Updated•7 years ago
|
Updated•7 years ago
|
Assignee | ||
Comment 3•7 years ago
|
||
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
Assignee | ||
Comment 4•7 years ago
|
||
It also only happens when the blur radius is 0.
Assignee | ||
Comment 5•7 years ago
|
||
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
Assignee | ||
Comment 6•7 years ago
|
||
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
Assignee | ||
Comment 7•7 years ago
|
||
(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.
Assignee | ||
Comment 8•7 years ago
|
||
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.
Keywords: regression,
regressionwindow-wanted
Comment 9•7 years ago
|
||
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.
Assignee | ||
Comment 10•7 years ago
|
||
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
Comment 11•7 years ago
|
||
Comment 12•7 years ago
|
||
The bug will occur on any platform where mApplySyntheticBold is used to enable synthetic bolding - OSX, Android, FFOS, GDI.
Comment 13•7 years ago
|
||
Just a guess but I suspect this happened when the gfxFont::Draw code was refactored in bug 1037340.
Assignee | ||
Updated•7 years ago
|
Component: Graphics, Panning and Zooming → Graphics: Text
Product: Firefox for Android → Core
Assignee | ||
Updated•7 years ago
|
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]
Updated•7 years ago
|
Whiteboard: [see comment 12 for affected platforms] → [see comment 12 for affected platforms], [gfx-noted]
Assignee | ||
Comment 14•7 years ago
|
||
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.
Assignee | ||
Comment 15•7 years ago
|
||
(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).
![]() |
||
Comment 16•7 years ago
|
||
With HWA off and attachment 8617729 [details] Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bd4287c14070&tochange=a6758d669350 Regressed by: bug 1037340
Blocks: 1037340
Keywords: regressionwindow-wanted
Assignee | ||
Comment 17•7 years ago
|
||
Thanks Alice!
Updated•7 years ago
|
Assignee: nobody → jfkthame
tracking-fennec: ? → +
Assignee | ||
Comment 18•7 years ago
|
||
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
Assignee | ||
Comment 19•7 years ago
|
||
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)
Assignee | ||
Comment 20•7 years ago
|
||
I'm still trying to work out a simple regression test for this. Any ideas appreciated.
Updated•7 years ago
|
Attachment #8624593 -
Flags: review?(jfkthame) → review+
Comment 21•7 years ago
|
||
Thanks for the fix! Seems like you could at least have a != reftest based on the second testcase here, I think?
Assignee | ||
Comment 22•7 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=67347731e38d
Assignee | ||
Comment 24•7 years ago
|
||
(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]
Assignee | ||
Comment 26•7 years ago
|
||
Attachment #8626557 -
Flags: review?(jfkthame)
Assignee | ||
Comment 27•7 years ago
|
||
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d0eb1370349 With part 1 reverted: https://treeherder.mozilla.org/#/jobs?repo=try&revision=66a5d4c047f0
Comment 28•7 years ago
|
||
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.)
Assignee | ||
Comment 29•7 years ago
|
||
Attachment #8626807 -
Flags: review?(jfkthame)
Assignee | ||
Updated•7 years ago
|
Attachment #8626557 -
Attachment is obsolete: true
Attachment #8626557 -
Flags: review?(jfkthame)
Assignee | ||
Comment 30•7 years ago
|
||
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9c0a7c15d65d With part 1 reverted: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8973270c7992
Updated•7 years ago
|
Attachment #8626807 -
Flags: review?(jfkthame) → review+
Assignee | ||
Updated•7 years ago
|
Whiteboard: [see comment 12 for affected platforms], [gfx-noted], [leave-open] → [see comment 12 for affected platforms], [gfx-noted]
Comment 32•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1e7d5ce4c80f
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in
before you can comment on or make changes to this bug.
Description
•