Java

JavaTM 2 SDK, v1.4 での
Java 2DTM の新機能

ドキュメントの目次

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

Beta 2 リリースで実施された変更点については、「J2SE 1.4 Beta 2 での変更点」を参照してください。 最終リリースで実施された変更点については、「J2SE 1.4 最終リリースでの変更点」を参照してください。

新しいパイプラインアーキテクチャ

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

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

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

次の呼び出しを Swing アプリケーション内で頻繁に使用する場合、上記の変更の効果が特に顕著に現れます。 コード共有の向上により、実行時のサイズも改善されます。

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

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

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

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

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

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

VolatileImage API の使用方法の詳細は、『The VolatileImage API User Guide』 ( PDF) を参照してください。

プラグイン可能なイメージ入出力フレームワーク

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

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

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

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

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

新しい JavaTM 印刷サービス

この変更に関連するバグ追跡レポート:
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 型データがサポートされました。 これらのクラスでは、新たにサポートされたデータ型に対応する、正規化されたコンポーネント値の範囲が定義されています。

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

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

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

java.awt.image.ComponentColorModel に、新規データ型に基づくコンストラクタ、および既存の ColorModel メソッドをオーバーライドするメソッドが新たに追加されました。 java.awt.image.SampleModel に、新規データ型の受け入れに使用する 2 つのメソッドが新たに追加されました。 java.awt.image.ComponentSampleModel に、新規データ型の受け入れに使用する 2 つのメソッドが新たに追加されました。 java.awt.image.BandedSampleModel では、新規データ型に対応するため、3 つのメソッドが編集されました。 java.awt.color.ColorSpace に、コンポーネントごとに正規化された最小値および最大値を決定するための 2 つのメソッドが新たに追加されました。 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 ラスタライザにこの機能を追加することにより、ネイティブラスタライザへの依存度が大幅に低下しました。 ネイティブラスタライザへの依存度低下には、次のようなメリットがあります。

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

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

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

OpenType フォントテーブルのサポート

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

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

数値形状のサポート

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

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

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

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

  1. ARABIC 数字の形状を持つ NumericShaper を作成する 
          Numeric Shaper nS
  	 = NumericShaper.getContextualShaper(NumericShaper.ARABIC)
  2. キー値 TextAttribute.NUMERIC_SHAPING を使用して、NumericShaper を Map 属性に追加する 
          Map map = new HashMap();
      map.put(TextAttribute.NUMERIC_SHAPING, nS);
  3. Map 属性を使用して TextLayout を作成する 
          FontRenderContext frc = ...;
      TextLayout layout = new TextLayout(text, map, frc);
  4. テキストを描画する 
          layout.draw(g2d, x, y);

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

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

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

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

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

次の新規 GlyphMetrics メソッドは、変換済みのフォントに対して操作を行います。 Porter-Duff の完全なサポート

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

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

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

フォントの変換属性をチェックする機能

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

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

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

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

FontRenderContext の同一性メソッド

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

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

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

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

Copyright © 1995-2001 Sun Microsystems, Inc. All Rights Reserved.

コメントの送付先: java2d-comments@sun.com 		Sun Microsystems, Inc
Java ソフトウェア