Work In Progress

Work done so far :

A working prototype of basic feature-set with Java 2D Metal rendering pipeline has been implemented for - 

1. 2D Primitives rendering
   1. implemented AA rendering for some primitives and painting types
   2. optimised geometry handling (no unnecessary MTLBuffer creation)
   3. improved stability: fixed some severe memory management problems in primitive handling
2. Image rendering. 
   1. improved stability: fixed several memory management problems
   2. native blit operations (Blit, IsoBlit) for almost all blit primitives (of MTLBlitLoops)
   3. all 32bpp raster formats with ‘opaque’ flags
   4. all alpha-composite modes (still unsupported extra-alpha)
   5. clipping, transform
   6. textures pool (to avoid reallocations for temporary textures) with restricted size (cleaned with LRU-strategy)
      
      1. fast search in pool
      2. no unnecessary sync
      3. blit without sampling if possible
3. Grayscale Text Rendering

It is available in the lanai repo https://hg.openjdk.java.net/lanai/lanai/

It can be tested with J2DDemo (available at - src/demo/share/jfc/J2Ddemo) that shows working / partially working / not-working Java 2D features with Metal rendering as compared with OpenGL rendering.
VM option -Dsun.java2d.metal=True needs to be passed in to switch rendering pipeline to Metal.
Also, antialiasing needs to be turned off (which is on by default in J2DDemo)

Work in Progress :

Current focus area is - Rendering performance evaluation :
As basic blocks of rendering have been implemented, it is a good time to check on rendering performance to evaluate how Metal rendering in Java 2D fares as compared to OpenGL rendering in Java 2D. As a first step, we are using below test benchmarkings - 

1. RenderPerfTest (available at - src/demo/share/java2d/RenderPerfTest)
2. J2DBench Tests (available at - src/demo/share/java2d/J2DBench) for drawing 2D primitives - line, rectangle, filled rectangle, ellipse, filled ellipse.

The performance numbers for Java 2D Metal rendering pipeline are not up to the mark as compared to the Java 2D OpenGL rendering pipeline. Multiple design level optimizations are being done to address this.

1. Reducing number of MTLRenderEncoders that get created per render pass
2. Reducing the number of drawPrimitives calls by batching data whenever possible
3. Using setNeedsDisplay flag of MTLLayer and updating the layer content on AppKit thread in a callback