On Fri, 24 Feb 2023 19:06:59 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> This fix properly supports colour rendering of Emoji on macOS
>>
>>
>> On other platforms the Emoji will be rendered as ordinary greyscale glyphs -
>> if there is font
>> support for the requested code point.
>>
>> A simple manual test is provided which uses a Text node, Label control
>> and editable TextField control.
>>
>> Some highlights of the code
>> - To determine if it is a color emoji glyph probe the 'sbix' font table
>> which is what is used by Apple
>> - Text runs now break at an Emoji glyph
>> - The Emoji is retrieved as an BGRA image - ie 4 channel including alpha
>> - It was necessary to retrieve the Emoji glyph bounds via a different
>> CoreText API since
>> the bounds that were being retrieved were wrong for the Emoji image -
>> causing clipping
>> - It was necessary to retrieve the Emoji code point advance via a CoreText
>> API since
>> the HMTX metrics were very wrong - causing overlapping glyphs
>> - drawString checks if it is an Emoji run and redirects to a new
>> drawColorGlyph method
>> which draws the image as a texture
>> - All 3 rendering pipelines have this support and have been verified on all
>> 3 desktop platforms
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java
> line 1456:
>
>> 1454: private boolean isSbixGlyph(int glyphID) {
>> 1455: if (sbixStrikes == null) {
>> 1456: synchronized (this) {
>
> This looks like a double-checked locking pattern, which is not guaranteed to
> be thread-safe.
>
> Suggestion: move the `synchronized` before the `if`.
or check for null again after synchronized(this)
-------------
PR: https://git.openjdk.org/jfx/pull/1047
