The bugtraq reports that correspond to this change are: 4228939 and 4268962
In the Java 2 SDK, version 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:
Other changes in the pipeline architecture have greatly improved the performance of:
Hardware Acceleration for Offscreen Images
The bugtraq report that corresponds to this change is: 4330166
The SDK 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:
For more information on using the VolatileImage
class, see the Full-Screen Exclusive Mode API lesson in the Java Tutorials.
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:
See Java Image I/O for more information on the Java Image I/O API.
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:
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:
The complete additional API is listed below.
java.awt.image.ColorModel includes three new methods to parallel existing methods:
The bugtraq report that corresponds to this change is: 4285083
The Unicode Bidirectional Algorithm analyzes text using the Unicode character properties and determines the direction of runs of the text. The algorithm is necessary to properly display bidirectional text, such as Hebrew and Arabic text, in the correct order.
The current implementation is all written in the Java programming language, but the SDK 1.4 will include efficient access from native font code so that Hebrew and Arabic text can be more efficiently rendered. The SDK 1.4 will provide access to the native code through the Java Native Interface.
The new public Bidi class implements the Unicode 3.0 Bidi Algorithm and allows access to information on the bidirectional reordering of text so that the mixed, bidirectional text is properly displayed.
The example BidiSample demonstrates some of the Bidi routines.
Font Rasterizer support for TrueType hinting
Before this release, the T2K font rasterizer used by Java 2D did not support font-hinting for TrueType fonts. As a result, when TrueType fonts did not always display with a consistent, attractive appearance. For this release, the T2K rasterizer has been modified to use the hints stored in the TrueType fonts.
By adding this functionality to the T2K rasterizer, dependency on native rasterizers has been greatly reduced. Reducing this dependency results in:
The bugtraq report that corresponds to this change is: 4285089
For the SDK 1.4, the Lucida fonts that are in the Java 2 SDK will be upgraded to contain hints. This will give the Java 2 SDK higher quality fonts that could be used in place of existing fonts or if no other fonts are available. Adding hints to the Lucida fonts also allows the new cross-platform rasterizer to hint the Lucida fonts contained in the SDK, which causes the Lucida fonts to be displayed in a more consistent and attractive manner.
The bugtraq report that corresponds to this change is: 4285161
The SDK 1.4 includes a new architecture for providing general OpenType font support. This new architecture provides international character support for contextual scripts like Thai, Indic, Arabic, and Hebrew. It also provides enhanced typographical support for Roman languages.
The bugtraq report that corresponds to this change is: 4210199
Currently, when Java 2D renders numerals surrounded by Arabic text, the numerals have Arabic (roman) shapes, which are the commonly expected numeral shapes in most western countries. However, people in a Hindi locale expect to see Hindi shapes.
A new attribute, TextAttribute.NUMERIC_SHAPING, and a new class, NumericShaper, enable you to shape ASCII digits to other Unicode decimal ranges.
For example, to cause a TextLayout instance to convert digits from European to Arabic:
Numeric Shaper nS
= NumericShaper.getContextualShaper(NumericShaper.ARABIC)
Map map = new HashMap();
map.put(TextAttribute.NUMERIC_SHAPING, nS);
FontRenderContext frc = ...;
TextLayout layout = new TextLayout(text, map, frc);
layout.draw(g2d, x, y);
The NumericShaper class includes 19 constants representing different Unicode decimal ranges, allowing you to convert to 19 different digit shapes, including Devanagari and Thai.
Improved Complex-Layout Support in GlyphVector
Prior to this release, clients could not access glyph-to-character mapping information from GlyphVector. Clients can use this information to find out which glyphs in the GlyphVector correspond to which characters. This release also defines new methods to get the precise bounds of the GlyphVector and of individual glyphs within a GlyphVector.
Note: Although clients can use GlyphVector and the glyph-to-character mapping information to implement selection and hit testing, most clients will find TextLayout and the Swing JTextArea and JTextField classes to be more useful and convenient.
These GlyphVector methods are new in the SDK 1.4:
Shape whose interior corresponds to the
visual representation of the specified glyph within this
GlyphVector, offset to x, y.GlyphVector when
rendered in a graphics with the given
FontRenderContext at the given location.GlyphVector is rendered in a Graphics
with the given FontRenderContext at the given
location.The bugtraq report that corresponds to this change is: 4380232
The AlphaComposite class provides alpha blending capabilities according to modes or rules established by Porter and Duff. Out of the 12 rules that Porter and Duff identified, the AlphaComposite API for the SDK, version 1.3 defines and implements only 8 of them:
For the SDK 1.4, AlphaComposite implements the remaining 4 Porter-Duff rules:
Support for Checking if Font has a Transform
The bugtraq report that corresponds to this change is: 4314043
As of the SDK 1.2 the Font object has a transform attribute that can be accessed with the Font.getTransform method. You can perform geometric transformations, such as rotating and shearing, on the Font by setting the transform attribute. However, most applications use the Size attribute rather than the transform to control the size and shape of characters. In this case, the transform is a simple identity transform.
Currently, the only way to determine if the transform is an identity transform is to call getTransform and inspect the returned AffineTransform. Unfortunately, calling getTransform requires the Font object to clone the AffineTransform because the transform is mutable.
Two new methods in the SDK 1.4 allow you to check if a Font object's transform is an identity tranform without creating a new AffineTransform:
true if the wrapped transform is an identity
transform.The bugtraq report that corresponds to this change is: 4328579
A FontRenderContext object encapsulates state about the graphics context and is used by GlyphVector and TextLayout. Three new methods in FontRenderContext allow you to compare the FontRenderContext in the GlyphVector against the one in the graphics context into which the GlyphVector draws:
These equals methods also have performance benefits because a client does not have to create an AffineTransform to perform an equality test.*As used on this web site, the terms "Java Virtual Machine" or "JVM" mean a virtual machine for the Java platform.
