[OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v13]

[Sergey Bylokhov]

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/5e61bf57...369c3d21

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:

> 321:      * more code just to support a few uncommon cases.
> 322:      */
> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {

Just curious, can we render LCD on 10.14+ via metal? Does it work fine?

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m line 73:

> 71: // Updates back buffer size of the layer if it's an OpenGL/Metal layer
> 72: // including all OpenGL/Metal sublayers
> 73: + (void) repaintLayersRecursively:(CALayer*)aLayer {

The operation of this code is still being investigated.  @prsadhuk please add a bugid here.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 148:

> 146:         rq.lock();
> 147:         try {
> 148:             // getMTLConfigInfo() creates and destroys temporary

Does it really create and destroy temporary surfaces/contexts?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m line 813:

> 811:     initTemplatePipelineDescriptors();
> 812:     // This block is not reached in current implementation.
> 813:     // Texture paint XOR mode rendering uses a tile based rendering using a SW pipe (similar to OGL)

Do we have a bugid to implement this later?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 59:

> 57:  * The offset in pixels of the Metal viewport origin from the lower-left
> 58:  * corner of the heavyweight drawable.  For example, a top-level frame on
> 59:  * Windows XP has lower-left insets of (4,4).  The Metal viewport origin

Do we really use these fields? "Windows XP"??

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

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