1495400 - Emoji larger than 98px are not displayed

Status: RESOLVED FIXED

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

Description

[Tobi Reif]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180920131237
Firefox for Android

Steps to reproduce:

Open
https://tobireif.com/non_site_stuff/emoji_max-size_test/the_max_emoji_size_in_mobile_firefox62_is_98px.html
in Mobile Firefox 62.

At font-size 98px, the emoji are shown:
https://app.crossbrowsertesting.com/public/ib8393c20a124bac/livetests/14400965/snapshots/z8bdb506801b9bf03607

Open
https://tobireif.com/non_site_stuff/emoji_max-size_test/emoji_size_99px.html
in Mobile Firefox 62.



Actual results:

At font-size 99px, the emoji are not shown:
https://app.crossbrowsertesting.com/public/ib8393c20a124bac/livetests/14400970/snapshots/z50f2fc8f9b4cfeb0ebc


Expected results:

The emoji should be displayed up to font-sizes of 146px (the limit of Mobile Chrome 69) or larger if possible.

Also see
https://tobireif.com/posts/maximum_font_size_for_emoji/

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Confirmed with Firefox 64.0a1 on a Nexus 5x running Android 8.1.0

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Confirmed on a recent 64.0a1 GeckoView Example build as well.

Comment 3

[Tobi Reif]

I hope this issue can get fixed.

Comment 4

[Lee Salzman [:lsalzman]]

Jamie, can you look into this? My guess is this is an issue with the Skia font size limits, though I don't have an Android dev environment set up at the moment to investigate myself...

Comment 5

[Tobi Reif]

I list some data at https://tobireif.com/posts/maximum_font_size_for_emoji/ , I'd be happy to update the info regarding Mobile Firefox as soon as it supports larger emoji.

Comment 6

[Jamie Nicol [:jnicol]]

Lee I'm really lost for where to even start looking for this, don't know the skia code at all. Do you have any pointers?

Comment 7

[Lee Salzman [:lsalzman]]

(In reply to Jamie Nicol [:jnicol] from comment #6)

Lee I'm really lost for where to even start looking for this, don't know the skia code at all. Do you have any pointers?

First try and verify that the FillGlyphs call is getting to the DrawTargetSkia, and if so, find out where the request is getting short-circuited inside Skia.

Comment 8

[Jamie Nicol [:jnicol]]

The code paths for 98px and 99px emoji diverge in SkGlyphRunListPainter::drawForBitmapDevice. For smaller than 98px ShouldDrawAsPath() returns false and we use drawUsingMasks(), which succeeds. For larger than 99px ShouldDrawAsPath() returns true and we use drawUsingPath() which fails.

drawUsingPath() fails in SkScalerContext_CairoFT::generatePath(), where the call to mozilla_LoadFTGlyph (which calls FT_Load_Glyph) fails. I couldn't trace the code any further in to FT_Load_Glyph unfortunately. The return value is 0x24 "Invalid Size Handle", not sure what that means. If I remove the FT_LOAD_NO_BITMAP flag from that call, then the call succeeds, but we still fail somewhere to render anything.

In ShouldDrawAsPath(), there's a call to SkTypeface::hasColorGlyphs(), which if true forces us not to use paths. But on android (and all platforms other than mac by the looks of it) this simply returns false all of the time.

Interestingly, on desktop linux, even when drawing as a path the emojis are rendered absolutely fine. My hunch is that the emoji implementation on Linux is vector-based can be rendered using paths, but emojis on Android (and Mac) are bitmaps so cannot. Does that make sense Lee?

If that is correct, then the solution would be to override SkTypeface::hasColorGlyphs on android to return something sensible rather than always false?

Comment 9

[Lee Salzman [:lsalzman]]

Attachment: Bug 1495400 - don't draw non-scalable FT faces as paths. r?jnicol

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d96ed1741bde
don't draw non-scalable FT faces as paths. r=jnicol

Comment 11

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/d96ed1741bde

Comment 12

[Tobi Reif]

Thanks!