Java SE 1.4でのJava 2Dの機能

新しいパイプライン・アーキテクチャ
オフスクリーン・イメージのハードウェア高速化
プラガブルなイメージ入出力フレームワーク
新しいJava Print Service API
追加のイメージ形式のサポート
public BIDIアルゴリズム
TrueTypeヒント用フォント・ラスタライザのサポート
ヒント情報を含むLucidaフォント
OpenTypeフォント表のサポート
数値形状のサポート
複雑なテキスト・レイアウトのサポート改善
Porter-Duffの完全なサポート
フォントの変換属性のチェックのサポート
FontRenderContextの同一性の新規メソッド

この変更に関連するバグ追跡レポート: 4228939および4268962

JDK 1.2および1.3では、Graphicsオブジェクトに対する一般操作により、Graphicsオブジェクトのキャッシュされたレンダリング・データが無効になることが頻繁にありました。このため、Graphicsオブジェクトのレンダリング情報が連続して再作成され、create()、setColor()、translate()など、単純で通常は問題の発生しない操作であっても、レンダリング・プロセスが中断されました。Swing階層のレンダリングはこれらの一般操作に大きく依存しているため、レンダリング・データの無効化および再作成により、多くのSwingアプリケーションでは低パフォーマンスでの再レンダリングしかできませんでした。

新たなパイプライン・アーキテクチャでは、次の実装変更により、パフォーマンスのオーバーヘッドが低減されました。

各種のレンダリング・パイプラインでのデータ共有方法を改善した。
レンダリング属性の変更に反応して実行されるコード、および作成されるガベージの量を低減した。
さまざまなグラフィックス・ルーチンの選択方法を改善した(ピクセルの形式および位置をコピーするルーチンなど)。

次の呼出しをSwingアプリケーション内で頻繁に使用する場合、上記の変更の効果が特に顕著に表れます。

getGraphics、Graphics.create()、およびGraphics.dispose()
Graphics.setColor()、Graphics.translate
Graphics.copyArea (特にコピー元とコピー先の領域がオーバーラップしている場合)。

コード共有の向上により、実行時のサイズも改善されます。

パイプライン・アーキテクチャに関するその他の変更により、次のパフォーマンスが大幅に改善されました。

draw(Shape)およびfill(Shape) (特にShapeがGeneralPathの場合)
拡大縮小されたdrawImage。
イメージのレンダリングや変更に干渉することなく、createImage()を複数回使用して作成されたオフスクリーン・イメージからの移動
createImage()を使ってダブル・バッファリング用のイメージ・バッファを作成するアプリケーションを、ネットワーク経由でリモートのX11に表示する操作。
不透明でないテキストのレンダリング。
RGBxピクセル記憶方式を使用するディスプレイ・カードを搭載したシステム(SGI Visual 320ワークステーションなど)。
アンチエイリアスがオフに設定された、-32768から32767までの範囲外のレンダリング座標。

この機能の詳細については、ホワイト・ペーパー「High Performance Graphics」を参照してください。

オフスクリーン・イメージのハードウェア高速化

この変更に関連するバグ追跡レポート: 4330166

JDK 1.4は、オフスクリーン・イメージ用のハードウェア高速化を提供するため、これらのイメージのレンダリングおよびコピーのパフォーマンスが向上します。ハードウェア高速化処理されたイメージの問題点は、Microsoft Windowsなどの一部のプラットフォームでは、状況により内容が突然失われる場合があり、しかもアプリケーションからそれを制御できないことです。新しいVolatileImageクラスを使用すると、ハードウェア高速化処理されたオフスクリーン・イメージを作成し、そのイメージの内容を管理できます。

新規APIには、次のものが含まれます。

java.awt.image.VolatileImage:
このクラスで表すイメージは、内容が突然失われる可能性は存在しますが、パフォーマンスは向上します。たとえばMicrosoft Windowsでは、このイメージはVRAMに格納でき、ハードウェアによる高速化を利用できます。このクラスに含まれるメソッドを呼び出して、イメージの内容を復元する必要があるかどうかを確認できます。
ComponentのcreateVolatileImage(w,h)。
このメソッドにより作成されるVolatileImageは、Componentと互換性があります。
createCompatibleVolatileImage(int width, int height)
このメソッドにより作成されるVolatileImageは、GraphicsConfigurationと互換性があります。
GraphicsDevice.getAvailableAcceleratedMemory
このメソッドは、高速化された利用可能なメモリーのバイト数を返します。

プラガブルなイメージ入出力フレームワーク

この変更に関連するバグ追跡レポート: 4101949

Java Image I/O APIは、様々な形式およびプロトコルのイメージの読取りおよび書込みをサポートする、プラガブルおよび拡張可能なフレームワークです。このAPIは、プラグインによって機能を実現しています。プラグインの大半はサード・パーティにより作成されています。主に旧バージョンのJava SDKとの互換性を維持するために、最小セットのプラグインを提供する場合には、適合実装のみが必要です。このAPIを使用するアプリケーションでは、イメージの格納形式や、それをサポートするために使用するプラグインの情報がなくても、イメージの読取りおよび書込みを実行できます。

基本的に、すべてのイメージ入出力操作は、1つ以上のイメージ、各イメージに関連付けられた1つ以上のプレビュー(サムネイル)イメージ、およびピクセル・データ以外のすべてのデータであるメタデータを含む、ストリームの読み取りまたは書込みで構成されます。

Java Image I/O APIを使用すると、アプリケーションで次の操作が可能になります。

インストール済みのプラグインを自動検出する
形式名、ファイル拡張子、ファイル内容、またはMIME形式に基づいてプラグインを選択する
複数のイメージが格納されたファイル内で、個別のイメージにアクセスする
読み取りおよび書込み処理の進捗状況をモニターする
ロード中のイメージを連続的に更新する
イメージ内の特定領域のみに読み取りおよび書込みを実行する
イメージの選択したバンドだけを読み取る
解像度に依存しないイメージの出力サイズを選択する
詳細なイメージおよびストリームのメタデータを取得する
ジェネリック・インタフェースを使用して、未知の形式を操作する
ランダム・アクセスおよびストリーミング・データ・ソースの両方を使用して、効率的に作業を行う
イメージを別の形式に変換する

Java Image I/O APIの詳細については、「Java Image I/O」を参照してください。

新しいJava印刷サービス

この変更に関連するバグ追跡レポート:
4285177および4360752

このAPIはJSR006で作成されたUnified Printing APIです。このAPIを使用することで、次のさまざまな印刷サービス機能をクライアント・アプリケーションから利用できます。

プリンタのブラウズおよび選択
プリンタの各種機能の検出
印刷ジョブに適したプリンタの選択
印刷ジョブの仕様

すべての機能はこのAPIを介して公開されるため、このAPIを優先的に利用できるのはサーバー・アプリケーションです。

印刷サービスにドキュメントをスプールする機能を、サーバー・アプリケーションから利用できます。以前は、印刷ジョブを生成するためにJavaアプリケーションから使用できたのは、グラフィックス呼び出しだけでした。

詳細については「Java印刷サービス」を参照してください。

floatおよびdoubleイメージ形式のサポート

この変更に関連するバグ追跡レポート: 4364491

SDK 1.4より前では、Java 2D APIには、floatまたはdoubleサンプル形式用のDataBufferサブクラスが存在しませんでした。Java Image I/O APIは、floatおよびdoubleイメージ形式の読み取りおよび書込みにこれらのクラスを必要とします。

floatおよびdoubleイメージ形式をサポートするため、SDK 1.4にDataBufferFloatおよびDataBufferDoubleという2つの新しいクラスが追加されました。DataBufferFloatクラスは、ピクセルのfloat配列をラップします。DataBufferDoubleクラスは、ピクセルのdouble配列をラップします。

既存のComponentColorModelおよびComponentSampleModelクラス実装も更新され、署名付きのshort、float、およびdouble型データがサポートされました。これらのクラスには、新たにサポートされたデータ型に対応する、正規化されたコンポーネント値の範囲の定義が含まれています。

既存のデータ型の場合は、0.0から1.0までの範囲を維持。
short型データの場合、値は -1.0から1.0までの範囲にスケーリングされる。
float型データの場合、範囲はfloatプリミティブ型の全範囲。
double型データの場合、値をfloatにキャストしてColorSpaceクラスと通信する必要があるため、floatプリミティブ型と同じ範囲。

ComponentColorModelクラスがピクセル・データの範囲を固定することはありません。アプリケーションは、適切な範囲にスケーリングすることが想定されています。ColorSpaceクラスに、正規化された最小値および最大値をコンポーネントごとに決定するためのメソッドが追加されました。アルファ成分値は、正規化された0.0から1.0までの範囲内になければなりません。

次に、追加された全APIのリストを示します。

java.awt.image.ColorModelに、既存のメソッドに対応する3つのメソッドが新たに追加されました。

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

java.awt.image.ComponentColorModelに、新規データ型に基づくコンストラクタ、および既存のColorModelメソッドをオーバーライドするメソッドが新たに追加されました。

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に、新規データ型の受け入れに使用する2つのメソッドが新たに追加されました。

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に、新規データ型の受け入れに使用する2つのメソッドが新たに追加されました。

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

java.awt.image.BandedSampleModelでは、新規データ型に対応するため、3つのメソッドが編集されました。

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

java.awt.color.ColorSpaceに、正規化された最小値および最大値をコンポーネントごとに決定するための2つのメソッドが新たに追加されました。

getMinValue(int component)
getMaxValue(int component)

java.awt.color.ICC_ColorSpaceに、2つの新規ColorSpaceメソッドをオーバーライドするメソッドが新たに追加されました。

public BIDIアルゴリズム

この変更に関連するバグ追跡レポート: 4285083

Unicode双方向アルゴリズムは、Unicode文字プロパティを使用してテキストを分析して、テキストの方向を判別します。このアルゴリズムは、ヘブライ語やアラビア語などの双方向テキストを正しい順序で適切に表示するために必要です。

現行の実装はすべてJavaプログラミング言語で記述されていますが、SDK 1.4ではネイティブのフォント・コードから効率的なアクセスが可能になるため、ヘブライ語やアラビア語のテキストをより効率的にレンダリングできるようになります。SDK 1.4では、Java Native Interfaceを使用してネイティブ・コードにアクセスできます。

新しいpublic BIDIクラスは、Unicode 3.0 BIDIアルゴリズムを実装し、テキストの双方向並べ替えに関する情報へのアクセスを提供します。このため、混在している双方向テキストが正しく表示されます。

サンプルのBidiSampleには、BIDIルーチンのいくつかが示されています。

TrueTypeヒント用フォント・ラスタライザのサポート

このリリースより前は、Java 2Dが使用するT2Kフォント・ラスタライザは、TrueTypeフォント用のフォント・ヒント機能をサポートしていませんでした。このため、TrueTypeフォントの表示は、常に一貫した美しいものではありませんでした。このリリースでは、TrueTypeフォント内に格納されたヒントを使用するようにT2Kラスタライザが変更されています。

T2Kラスタライザにこの機能を追加することにより、ネイティブ・ラスタライザへの依存度が大幅に低下しました。ネイティブ・ラスタライザへの依存度低下には、次のようなメリットがあります。

TrueTypeフォントのヒント機能が、ネイティブのラスタライザではなくクロス・プラットフォームのT2Kラスタライザで実行されるため、移植性が向上する。
オンスクリーンとオフスクリーンの両方で、描画に同じラスタライザが使用されるため、TrueTypeフォントのメトリックス表示の一貫性が向上する。

ヒント情報を含むLucidaフォント

この変更に関連するバグ追跡レポート: 4285089

SDK 1.4では、Java SE内のLucidaフォントがアップグレードされ、ヒント情報が含まれるようになりました。このため、Java SEで既存のフォントの代用として、または他のフォントが利用できない場合に使用されるフォントの品質が向上しました。Lucidaフォントにヒント情報を追加することにより、新しいクロスプラットフォーム・ラスタライザが、SDKのLucidaフォント内のヒントを使用することも可能になりました。このため、Lucidaフォントがより一貫して美しく表示されるようになります。

OpenTypeフォント表のサポート

この変更に関連するバグ追跡レポート: 4285161

SDK 1.4に、一般的なOpenTypeフォント・サポートを提供するアーキテクチャが新たに含まれるようになりました。この新たなアーキテクチャは、タイ語、インド語派、アラビア語、ヘブライ語などの筆記体活字に対応した、国際的な文字サポートを提供します。また、ローマ字言語の拡張入力サポートも提供します。

数値形状のサポート

この変更に関連するバグ追跡レポート: 4210199

現在のところ、アラビア語のテキストで囲まれた数値をJava 2Dでレンダリングすると、数値が大半の西欧諸国で一般に使用されているアラビア数字(ローマ数字)の形状になります。しかし、ヒンディ語ロケールでは、ヒンディ語の形状で表示されることが期待されます。

新規属性TextAttribute.NUMERIC_SHAPING、および新規クラスNumericShaperを使用すると、ASCII数字をほかのUnicode 10進数の範囲に変更できます。

たとえば、TextLayoutインスタンスで、数字をヨーロッパ言語からアラビア語に変換する場合、次の操作を実行します。

ARABIC数字の形状を持つNumericShaperを作成します。

      Numeric Shaper nS 
         = NumericShaper.getContextualShaper(NumericShaper.ARABIC)

キー値TextAttribute.NUMERIC_SHAPINGを使用して、NumericShaperをMap属性に追加します。
```
      Map map = new HashMap();
      map.put(TextAttribute.NUMERIC_SHAPING, nS);
```

Map属性を使用してTextLayoutを作成します。

      FontRenderContext frc = ...;
      TextLayout layout = new TextLayout(text, map, frc);

テキストをレンダリングします。
```
      layout.draw(g2d, x, y);
```

NumericShaperクラスには、種類の異なるUnicode 10進数を表す定数が19個あります。このため、デーバナーガリー文字やタイ語文字を含む19個の異なる形状に数字を変換できます。

GlyphVectorでの複雑なレイアウトのサポート改善

このリリースより前には、クライアントは、グリフから文字へのマッピング情報にGlyphVectorからアクセスすることはできませんでした。この情報は、クライアントがGlyphVector内のグリフがどの文字に対応するかを確認するために使用できます。このリリースでは、GlyphVectorおよびGlyphVector内の各グリフの正確な境界を取得する新規メソッドも定義されています。

注: クライアントはGlyphVectorおよびグリフから文字へのマッピング情報を使用して選択およびヒット判定を実装できますが、大半のクライアントでは、TextLayoutおよびSwingのJTextAreaクラスやJTextFieldクラスを使用する方が便利かつ有用です。

SDK 1.4では、次のGlyphVectorメソッドが新たに追加されました。

getGlyphCharIndex(int glyphIndex)
指定されたグリフの文字インデックスを返す。(文字インデックスは、グリフによって表される最初の論理文字のインデックス)
getGlyphCharIndices(int beginGlyphIndex, int numEntries, int[] codeReturn)
指定されたグリフの文字インデックスを返す。
getGlyphOutline(int glyphIndex, float x, float y)
内部が、このGlyphVector内のx,y に対するオフセットで指定されたグリフの視覚表現に対応するShapeを返す。
getPixelBounds(FontRenderContext renderFRC, float x, float y)
グラフィックス内の指定された位置に、指定されたFontRenderContextを使用してレンダリングする際の、このGlyphVectorのピクセル境界を返す。
getGlyphPixelBounds(int index, FontRenderContext renderFRC, float x, float y)
このGlyphVectorが、指定されたFontRenderContextを使用して指定された位置でGraphicsにレンダリングされる際、インデックスでのグリフのピクセル境界を返す。

次の新規GlyphMetricsメソッドは、変換済みのフォントに対して操作を行います。

getAdvanceX()
グリフの有効幅のXコンポーネントを返します。
getAdvanceY
グリフの有効幅のYコンポーネントを返します。

Porter-Duffの完全なサポート

この変更に関連するバグ追跡レポート: 4380232

AlphaCompositeクラスは、PorterおよびDuffによって確立されたモードまたは規則に従って、アルファ・ブレンド機能を提供します。SDKバージョン1.3のAlphaComposite APIで定義および実装されている規則は、PorterとDuffが発見した12の規則のうちの8つに過ぎません。

Clear
A (Src)
A over B (SrcOver)
B over A (DstOver)
A in B (SrcIn)
B in A (DstIn)
A held out by B (SrcOut)
B held out by A (DstOut)

SDK 1.4では、AlphaCompositeは残りの4つのPorter-Duff規則を実装します。

B (Dst)
A atop B (SrcAtop)
B atop A (DstAtop)
A xor B (Xor)

フォントの変換属性のチェックのサポート

この変更に関連するバグ追跡レポート: 4314043

SDK 1.2以降、Fontオブジェクトが保持する変換属性には、Font.getTransformメソッドを使ってアクセスできます。変換属性を設定することにより、Fontの回転、変形などの幾何学的変換を実行できます。ただし、大半のアプリケーションでは、変換ではなくSize属性を使用して文字のサイズや形状を制御します。この場合、変換は単純な恒等変換になります。

現在、変換が恒等変換かどうかを判別する唯一の方法は、getTransformを呼び出して、返されるAffineTransformを調べることです。しかし、getTransformを呼び出すには、FontオブジェクトがAffineTransformのクローンを作成することが求められます。これは、変換が可変であるためです。

SDK 1.4で新たに追加された次の2つの新しいメソッドを利用すると、AffineTransformを新たに作成しなくても、Fontオブジェクトの変換が恒等変換かどうかをチェックできます。

java.awt.Font.isTransformed:
このFontオブジェクトが非恒等AffineTransform属性を保持する場合、trueを返します。
java.awt.font.TransformAttribute.isIdentity:
ラップされた変換が恒等変換である場合、trueを返します。

FontRenderContextの同一性の新規メソッド

この変更に関連するバグ追跡レポート: 4328579

FontRenderContextオブジェクトは、グラフィックス・コンテキストの状態をカプセル化し、GlyphVectorおよびTextLayoutにより使用されます。FontRenderContextに新たに追加された次の3つのメソッドを利用すると、GlyphVector内のFontRenderContextを、GlyphVectorの描画先グラフィックス・コンテキスト内のFontRenderContextと比較できます。

これらの同一性メソッドを利用すると、一致検査を実行するためにクライアントがAffineTransformを作成する必要がないため、パフォーマンス上の利点もあります。

*このWebサイトで使用されている用語「Java仮想マシン」または「JVM」は、Javaプラットフォーム用の仮想マシンを表します。

連絡先