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

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS [v2]
From:       Dmitry Batrak <dbatrak () openjdk ! java ! net>
Date:       2021-04-19 7:34:39
Message-ID: oaqhk84hC7vz9d5atQVqA-hl9_kDzcHqdY7SJnF-GDk=.75f7421b-b2e8-4f4e-a13c-1d56df366f2d () github ! com
[Download RAW message or body]

On Fri, 19 Mar 2021 13:48:12 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.
> 
> 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

Any chance for a second review?

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

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


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