> 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3007/files
  - new: https://git.openjdk.java.net/jdk/pull/3007/files/a9b2e9c3..c8bff122

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3007&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3007&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3007/head:pull/3007

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

Reply via email to