Implement a Java 2D internal rendering pipeline for macOS using the Apple Metal API as alternative to the existing pipeline, which uses the deprecated Apple OpenGL API.
- Provide a fully functional rendering pipeline for the Java 2D API that uses the macOS Metal framework.
- Be ready in the event Apple removes the deprecated OpenGL API from a future version of macOS.
- Ensure transparency of the new pipeline to Java applications.
- Ensure functional parity of the implementation with the existing OpenGL pipeline.
- Provide performance as good or better than the OpenGL pipeline in select real applications and benchmarks.
- Create a clean architecture that fits into the existing Java 2D pipeline model.
- Co-exist with the OpenGL pipeline until it is obsolete.
- Pass the Java TCK.
- It is not a goal to remove or disable the existing OpenGL pipeline.
- It is not a goal to add any new Java or JDK APIs. This is all internal implementation.
Two major factors motivate the introduction of a new Metal-based rendering pipeline on macOS:
Apple deprecated the OpenGL rendering library in macOS 10.14, in September 2018. Java 2D on macOS is completely reliant on OpenGL for its internal rendering pipeline, so a new pipeline implementation is needed.
Apple claims that the Metal framework, their replacement for OpenGL, has superior performance.
Most graphical Java applications are written using the Swing UI toolkit, which renders via the Java 2D API. Internally, Java 2D can use software rendering plus a blit to the screen or it can use a platform-specific API, such as X11/Xrender on Linux, Direct3D on Windows, or OpenGL on macOS. These platform-specific APIs typically offer much better performance than software rendering and generally off-load the CPU. Metal is the new Apple platform API for such rendering, replacing the deprecated OpenGL API. (The name has nothing to do with the Swing “Metal” Look and Feel; that is just a coincidence.)
We will update existing internal JDK code and create new code to utilize the Metal framework in a similar way as we already utilize the other platform-specific APIs. We will also investigate opportunities to leverage new capabilities of the Metal framework, such as more concurrent rendering.
Refactoring outside of the OpenGL/Metal code is expected to be minimal.
This implementation of a new rendering pipeline will not introduce any new Java API. However, if necessary we will update the Java AWT Native Interface to provide access to a Metal native drawing surface. That is a native code interface, and thus does not affect Java language applications.
The Metal pipeline will co-exist with the OpenGL pipeline. When a graphical application starts up, one or the other will be chosen. For now, OpenGL will remain the default. Metal will be used only if it is specified on startup or if the initialization of OpenGL fails, as would happen in a future version of macOS with no OpenGL support.
Assuming that Apple provides some period of time before removing OpenGL support, after this JEP is integrated an application can opt-in to Metal by specifying
-Dsun.java2d.metal=true on the
java command line. The Metal rendering pipeline will be made the default in a later release.
Work on this JEP is being conducted in Project Lanai.
Testing the functionality of the new pipeline does not require new test development, since no Java 2D APIs will change. Existing tests and real-world applications will suffice. These include:
- JDK jtreg regression tests
- JCK Tests
- Java 2D and Swing Demos
- IDEs such as Intellij IDEA and Netbeans, as examples of large-scale real world applications
To test performance, we will use:
- J2DBench, a Java 2D benchmarking application included in JDK
- RenderPerfTest, a custom stress test that renders multiple objects of the same primitive type and measures frames per second (FPS) developed in Project Lanai
- IntelliJ IDEA IDE performance
These lists are subject to change as the work progresses.
Risks and Assumptions
Prototype work to date in Project Lanai suggests that we are well on the way to exceeding our goals and metrics. Until we are nearly finished, however, we cannot be sure that Metal will perform as well as expected in all cases. For example, so far no way has been discovered to efficiently implement the XOR operation which, although niche, is required.