RFR: 8269806: Emoji rendering on Linux [v2]

[Phil Race]

On Thu, 24 Mar 2022 22:36:28 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269806: Fix builds with old Freetype (before 2.5)

See my follow up message. Same occurs when using the font directly - not Dialog.
It is opening "Noto Color Emoji" from /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf

The B&W ones that render properly in MY image are beacuse Dialog uses as its main font 
Deja Vu Sans has B&W emoticons defined as normal TrueType outlines.

Ignore those - it is the garbage ones that are the problem.

Note that JDK does not use ANY of Linux's libfontconfig's fancy aliasing of fonts etc.
If we report that file, and that name, that is what is used - end of story.

If  you do that NOT A SINGLE glyph from the font renders properly with AA=OFF.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4798