The Wayback Machine - https://web.archive.org/web/20070516132229/http://openjdk.java.net:80/groups/2d/

The 2D Graphics Group

The 2D Graphics group is centered around people interested in the creation and maintanence of the 2D API and implementation.

Introduction

The Java 2D API and its implementation is often not easily separable from other parts of the Java platform.

Generally it implements geometry, text and image APIs and renders these to screen and printer devices using software, or hardware accelerated means, depending on implementation and/or application or user specified system properties.

Very briefly, the core of the API is the class java.awt.Graphics2D. It provides methods for the rendering operations, as well as controlling the state of the Graphics instance.

There's a large supporting cast of classes in the packages

Image I/O provides the means load and save sampled images where the in-process image use Java2D's image format.

javax.print is tightly integrated with the java.awt.print package which is the 2D API for rendering to printer graphics devices.

There is a wealth of information on the Java 2D API for application developers. e.g. See:


Regarding Java 2D's source code.

All of the Java 2D's code is in the "j2se" workspace, so all references below are relative to the root of the "j2se" workspace.

Most of the relevant sources have a java and native component.

The Java 2D-related java code is can be browsed from Netbeans by opening the "awt2d" project. This project also contains the files belonging to AWT - see the README file in the "awt2d" project directory. (note that with some effort the native code can be worked on from Netbeans as well, see the README mentioned above)

All sources are either 'share' or 'windows' or 'solaris', the latter of which in fact includes Linux(TM) and is so named for historical reasons and because in practice the Solaris(TM) code and the Linux code are usually so close that a few ifs or ifdefs suffice to distinguish them. This is partially explained by observing that for 2D, Solaris and Linux are just both platforms for X11.

Most of 2D's code is in 'share'. Even the OpenGL code.There is a still significant but lesser amount of code that is specific to X11 or Win32/GDI.  But here for brevity we just point out the shared locations.

These all are under "src/share". The Java classes are located corresponding to the package hierarchy. E.g. java.awt.Graphics2D is in:

Implementation (non-public) classes are generally in a package starting with "sun.". E.g.:

There are exceptions, notably:

Java 2D also has a substantial amount of native code. This is located in similar manner :

(Note that the platform-specific native code is naturally in the corresponding src/[platform]/native/.. directory)

The shared code location contains essentially complete implementations of everything since 2D has its own code for everything needed to implement the API.

The relevant j2se workspace make files are structured in the following way:

One can also build the 2d source tree from the "awt2d" Netbeans project (both native and java).


Non-open Java 2D source code.

Some parts of Java 2D are not part of the initial OpenJDK source release, or are different than in the commercial releases from Sun and its licensees. We want to remove these so that the full OpenJDK can be built entirely from sources.

Generally the reason for this is that the code was licensed by Sun from a 3rd party. Not all code that is as yet unreleased is certain to stay that way. We are still working on disentangling the code that cannot be opened from code that can. In some cases this comes down to parts of a source file.

Here's a summary of the encumbrances that were identified and the current state.

  1. Native code color management system

    The Color Management System - a C library - and several color profile files were licensed for use in JDK 1.2. To replace this we identified "Little CMS" (lcms) as a suitable replacement open source library. We have implemented a pluggable layer, so that for now the commercial version can use the old CMS and OpenJDK can use lcms.

    src/share/classes/sun/java2d/cmm contains the pluggable layer. CMSManager.java is the class called by 2D code that needs to invoke color operations. On first load CMSManager uses the java.util.ServiceLoader class to locate an implementation of the PCMM interface.

    Glue code for LittleCMS that implements that interface is in:

    • src/share/classes/sun/java2d/cmm/lcms

    In turn it loads the native lcms library.

    The source code for OpenJDK's copy of this is in:

    • src/share/native/sun/java2d/cmm/lcms

    Color profiles are located in:

    • src/share/lib/cmm/lcms

    Status : At the time of launch this is mostly resolved.

  2. Font rasteriser

    The font rasteriser is a native library licensed for use by Java 2D. To replace it in the OpenJDK we have identified freetype as the most viable cross-platform alternative. It is already used by the native desktops on Linux and OpenSolaris.

    The interfaces to the closed rasteriser are found in:

    • src/share/native/sun/font/scalerMethods.c
    • src/share/native/sun/font/t2kScalerContext.cpp

    Similarly, but not identically, to the CMS case, there will be a pluggable layer so that the commercial JDK can use the old rasteriser whilst OpenJDK uses freetype.

    Status : At the time of launch work to resolve this is largely complete but not ready enough to be in the released source. Hopefully this will happen soon. But for launch, OpenJDK grabs a pre-built version of the rasteriser from a commercial binary built from the same open sources, but including the closed sources.

  3. Antialiasing graphics rasteriser.

    The Ductus rasteriser is a small set of Java classes backed by a native library.

    It is used by the JDK to perform path stroking and filling. BasicStroke uses it to apply stroke parameters, such as dashing to create an output path. It can also take a shape and produce rectangles of alpha pixels which fill that shape.

    The JDK classes which utilise it are :

    • src/share/classes/java/awt/BasicStroke.java
    • src/share/classes/sun/java2d/pipe/DuctusRenderer.java
    • src/share/classes/sun/java2d/pipe/DuctusShapeRenderer.java
    • src/share/classes/sun/java2d/pipe/ShapeSpanIterator.java

    These do not represent a clean separable interface. ShapeSpanIterator directly implements the Ductus PathConsumer Java interface, and has a native implementation which uses native Ductus defined structures. The code which calls these is in:

    • src/share/native/sun/java2d/pipe/ShapeSpanIterator.c

    A layer which abstracts away the particulars of the Ductus code would make it easier to plug-in an alternative solution.

    Status: At the time of launch this still needs to be resolved.  The Pisces renderer which is already open-sourced is the most promising candidate identified. But it needs work so that rather than take over rendering, it can be integrated with the 2D rendering pipe.

    Pisces sources are at :

Community

close