On Fri, 19 Mar 2021 13:48:12 GMT, Dmitry Batrak <dbat...@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 two additional
> commits since the last revision:
>
> - 8263583: Emoji rendering on macOS
>
> extended test case to cover different types of target surfaces
> - 8263583: Emoji rendering on macOS
>
> implementation for Metal rendering pipeline
Marked as reviewed by prr (Reviewer).
src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTextRenderer.m line
327:
> 325: }
> 326:
> 327: MTLPaint* storedPaint = nil;
should this be static ?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3007
