-
-
Notifications
You must be signed in to change notification settings - Fork 17
History and context
Java uses pluggable rasterizers for antialiased rendering. Each rasterizer implements the sun.java2d.pipe.RenderingEngine
, gets registered in SPI (Service Provider Interface), and once available in the boot classpath, can be enabled via system variables.
The two basic platform independent renderers are Ductus and Pisces. The Ductus rasteriser is a small set of Java classes backed by a native library used to perform path stroking and filling. It is available by default in Oracle JDK, it's closed source, and has serious issues scaling up in a multi-threaded enviroment, as it can rasterizer only one java.awt.Shape at a time.
The Pisces rasterizer is instead a pure java, open source rasterizer used by the OpenJDK. It has no scalability issues, but performance is rather poor.
There are other rasterizers, such as the XRender one, which relies on native and platform specific support (Cairo). For reference, here is a an old single threaded performance comparison between Ductus, XRender and Pisces
Laurent Bourges started looking into Pisces performance around March 2013 and soon after provided a first patch to improve its performance.
The patches evolved over time, and Andrea Aime started provided some benchmarking tools geared towards improving both performance and scalability in the context of web map rendering.
While the patches spurred some interested, it became soon clear that getting them accepted in OpenJDK would have proven difficult.
After a few months of hiatus we decided to move on with the development outside of the OpenJDK community, leveraging the ability to plug other implementation of sun.java2d.pipe.RenderingEngine
, and setting up a true open source project to host the evolution of these Pisces patches: the Marlin-renderer was thus born.
The primary objective of the project is build a pure java renderer that can match and/or surpass Ductus performance in the single threaded case, and maintain good scalability, making sure that all CPU cores can rasterize shapes in parallel.
The secondary goal is to maintain the ability to contribute these changes back to OpenJDK and have, one day, Marlin become the default software rasterizer for the open source JDK (and, why not, for the Oracle JDK too!).