[OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS [v3]

[Sergey Bylokhov]

On Fri, 7 May 2021 08:02:36 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
>> found while preparing the pull request, fixed.
>> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
>> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
>> Notable implementation details are listed below.
>> 
>> **Glyph image generation**
>> 
>> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
>> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
>> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
>> are not scaled proportionally with font size (as they do for vector fonts).
>> 
>> **Glyph image storage**
>> 
>> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
>> of storage per pixel. Color components are stored in pre-multiplied alpha format.
>> 
>> **Glyph rendering**
>> 
>> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
>> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
>> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
>> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
>> specific segments of GlyphList.
>> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
>> (most text renderers don't need this information).
>> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
>> and by re-using existing Blit primitive in off-screen renderers.
>> 
>> **Testing**
>> 
>> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
>> rendered for the emoji character, when painting to BufferedImage.
>> 
>> Existing tests pass after the change.
>
> Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263583: Emoji rendering on macOS
>   
>   add 'static' modifier to a variable

It is not necessary to get reapprove for push, it is just a good style to do.

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

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