• New Pipeline Architecture
• Hardware Acceleration for OffscreenImages
• Pluggable Image I/OFramework
• New Java Print Service API
• Support for additional ImageTypes
• Public Bidi Algorithm
• Font Rasterizer support for TrueType Hinting
• Hinted Lucida Fonts
• OpenType Font Table Support
• Support for Numeric Shaping
• Improved Complex Text Layout Support
• Complete Porter-Duff Support
• Support for Checking if Font has a Transform
• New Equality Methods for FontRenderContext

---

New Pipeline Architecture

The bugtraq reports that correspond to this change are: 4228939 and 4268962

In the JDK 1.2 and 1.3 common operations on a Graphics object often invalidated the rendering data cached for this Graphics object. This invalidation interrupted the rendering process by causing continuous re-creation of rendering information for the Graphics object, even for such simple and benign operations as create(), setColor(), and translate(). Because the rendering of Swing hierarchies relies heavily on these common operations, the invalidation and re-creation of rendering data caused poor repaint performance for many Swing applications.

The new pipeline architecture reduces this performance overhead with several implementation changes that:

• Improve the way that data is shared by the various rendering pipelines.
• Reduce the amount of code executed and garbage created when responding to changes in the rendering attributes.
• Improve the way that various graphics routines are chosen such as the routines that copy pixels from one format and location to another.

These changes are especially noticeable when the following calls are used frequently, as they are in Swing applications:

• getGraphics, Graphics.create() and Graphics.dispose()
• Graphics.setColor(), Graphics.translate
• Graphics.copyArea, especially when the source and destination regions overlap.

The runtime footprint should also be improved through better code sharing.

Other changes in the pipeline architecture have greatly improved the performance of:

• draw(Shape) and fill(Shape), especially when the Shape is a GeneralPath
• scaled drawImage.
• Blitting from an offscreen image created with createImage() multiple times without any intervening rendering or modifications to that image
• Remote X11 display over the network of applications that use createImage() to create an image buffer for double buffering.
• Rendering non-opaque text.
• Systems, such as the SGI Visual 320 workstation, which have display cards that use an RGBx format for pixel storage.
• Rendering coordinates outside of the range -32768 to 32767 with antialiasing turned off.

For more information on this feature, see the whitepaper, High Performance Graphics.

Hardware Acceleration for Offscreen Images

The bugtraq report that corresponds to this change is: 4330166

The JDK 1.4 provides access to hardware acceleration for offscreen images, resulting in better performance of rendering to and copying from these images. One problem with hardware-accelerated images is that, on some platforms such as Microsoft Windows, their contents can be lost at any time due to circumstances beyond the application's control. The new VolatileImage class allows you to create a hardware-accelerated offscreen image and manage the contents of that image.

This new API includes:

• java.awt.image.VolatileImage:
  This class represents an image whose content can be lost at any time, but provides performance benefits. For example, on Microsoft Windows this image can be stored in VRAM and can benefit from hardware acceleration. The class includes methods that you can call to find out if the contents of the image need to be restored.
• createVolatileImage(w,h) in Component.
  This method creates a VolatileImage that is compatible with the Component.
• createCompatibleVolatileImage(int width, int height)
  This method creates a VolatileImage that is compatible with the GraphicsConfiguration.
• GraphicsDevice.getAvailableAcceleratedMemory
  This method returns the number of bytes of available accelerated memory.

Pluggable Image I/O Framework

The bugtraq report that corresponds to this change is: 4101949

The Java Image I/O API is an pluggable, extensible framework that supports reading and writing images of various formats and protocols. The API provides this support through plug-ins, most of which will be written by third parties. A conforming implementation will only be required to provide a minimal set of plug-ins, principally for compatibility with previous versions of the Java SDK. An application using this API should be able to read and write images without knowing the image's storage format or the plug-in used to support the format.

Fundamentally, all image I/O operations consist of reading or writing streams that contain one or more images, one or more preview (thumbnail) images associated with each image, and metadata, which is everything other than pixel data.

The Java Image I/O API allows applications to:

• Auto-detect installed plug-ins
• Choose plug-ins based on format name, file suffix, file contents, or MIME type
• Access individual images in multi-image files
• Monitor reading and writing progress
• Provide progressive updates of images being loaded
• Read or write only a region of interest of an image
• Read only selected bands of an image
• Choose the output size of resolution-independent imagery
• Retrieve detailed image and stream metadata
• Work with unknown formats using generic interfaces
• Work efficiently with both random-access and streaming data sources
• Transcode between different formats

See Java Image I/O for more information on the Java Image I/O API.

New Java Print Service

The bugtraq reports that corresponds to this change are:
4285177 and 4360752

This API is the product of JSR006, Unified Printing API, and will allow client applications to provide rich access to the capablities of print services available including:

• Printer browsing and selection
• Discovery of the capablities of printers
• Selection of printers for a printer job
• Specification of a printer job.

Since all capabilities will be exposed through the API, server applications become first class citizens of this API.

Server applications can be beneficiaries of the capabilities for spooling documents to print services, whereas previously only graphics calls could be used to generate printer jobs from Java applications.

See Java Print Service for more information.

Support for float and double Image Types

The bugtraq report that corresponds to this change is: 4364491

Prior to the SDK 1.4, the Java 2D API did not have DataBuffer subclasses for float or double sample types. The Java Image I/O API needs these classes to read and write float and double image types.

The SDK 1.4 contains two new classes to provide float and double image type support: DataBufferFloat and DataBufferDouble. The DataBufferFloat class wraps float arrays of pixels. The DataBufferDouble class wraps double arrays of pixels.

The existing ComponentColorModel and ComponentSampleModel class implementations have also been updated to support signed short,float, and double data. These classes include definitions of the normalized ranges of component values for the newly-supported data types:

• For the existing data types, the range remains 0.0 to 1.0.
• For short data, the values are scaled to between -1.0 and 1.0.
• For float data, the range is the full range of the float primitive type.
• For double data, the range is also the range of the float primitive type, since values must be cast to float to interact with the ColorSpace class.

The ComponentColorModel class will not clamp the pixel data. Applications are expected to scale to the appropriate range. Methods are added to the ColorSpace class to determine per component minimum and maximum normalized values. Alpha component values must still range from 0.0 to 1.0 normalized.

The complete additional API is listed below.

java.awt.image.ColorModel includes three new methods to parallel existing methods:

• getDataElement(float[] normComponents, int normOffset)
• getDataElements(float[] normComponents, int normOffset, Object obj)
• getNormalizedComponents(Object pixel, float[] normComponents, int normOffset)

java.awt.image.ComponentColorModel includes a new constructor based on the new datatypes and new methods to override the existing ColorModel methods:

• ComponentColorModel(ColorSpace colorSpace, boolean hasAlpha, boolean isAlphaPremultiplied, int transparency, int transferType)
• getRed(Object inData)
• getGreen(Object inData)
• getBlue(Object inData)
• getAlpha(Object inData)
• getDataElements(int rgb, Object pixel)
• coerceData(WritableRaster raster, boolean isAlphaPremultiplied)
• createCompatibleWritableRaster(int w, int h)
• createCompatibleSampleModel(int w, int h)

java.awt.image.SampleModel includes two new methods to accept the new datatypes:

• getDataElements(int x, int y, int w, int h, Object obj, DataBuffer data)
• setDataElements(int x, int y, int w, int h, Object obj, DataBuffer data)

java.awt.image.ComponentSampleModel includes two methods to accept the new datatypes:

• createDataBuffer()
• getDataElements(int x, int y, Object obj, DataBuffer data)

java.awt.image.BandedSampleModel has three methods that were edited to accept the new datatypes:

• createDataBuffer()
• getDataElements(int x, int y, Object obj, DataBuffer data)
• setDataElements(int x, int y, Object obj, DataBuffer data)

java.awt.color.ColorSpace includes two new methods determine per component minimum and maximum normalized values:

• getMinValue(int component)
• getMaxValue(int component)

java.awt.color.ICC_ColorSpace includes new methods override the two new ColorSpace methods.