[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Integrated: 8263583: Emoji rendering on macOS
From:       Dmitry Batrak <dbatrak () openjdk ! java ! net>
Date:       2021-05-31 7:18:24
Message-ID: wloTI0pbaHjADqLgqPY87_n5dAsFGl2P0kfhpfoVrLY=.61b95132-5856-43c8-af0c-97bd0a4d78ec () github ! com
[Download RAW message or body]

On Mon, 15 Mar 2021 10:25:50 GMT, Dmitry Batrak <dbatrak@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.

This pull request has now been integrated.

Changeset: 236bd89d
Author:    Dmitry Batrak <dbatrak@openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/236bd89dc3be60cac13099618f5e6518437a5098
                
Stats:     938 lines in 29 files changed: 795 ins; 31 del; 112 mod

8263583: Emoji rendering on macOS

Reviewed-by: serb, prr

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

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


[prev in list] [next in list] [prev in thread] [next in thread]