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

---

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

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

Java 2 SDK バージョン 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

SDK 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
  このメソッドは、高速化された利用可能なメモリーのバイト数を返します。

VolatileImage クラスの使用方法の詳細は、Java チュートリアルの「Full-Screen Exclusive Mode API」レッスンを参照してください。

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

この変更に関連するバグ追跡レポート: 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 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 メソッドが新たに追加されました。

• 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 と比較できます。

• equals(FontRenderContext)
• equals(Object)
• hashCode()

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

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