Java 2Dプロパティのサマリーについては、「Java 2Dのプロパティ」を参照してください。
別のパイプラインを選択したりパイプラインのプロパティを操作したりすれば、問題の原因を特定できたり、しばしば回避方法を発見できたりする可能性があります。
通常、構成で使用されるデフォルトのパイプラインを確認することで、Java 2Dパイプラインの問題のトラブルシューティングを行うことができます。次に、パイプラインを別のものに変更するか、デフォルト・パイプラインのプロパティを変更します。
問題が解消すれば、回避方法が見つかったことになります。問題が継続する場合は、別のプロパティを変更するか別のパイプラインに変更してみます。
Java 2Dでは一連のパイプラインが使用されますが、これは大まかに、プリミティブをレンダリングするためのさまざまな方法として定義できます。これらのパイプラインは次のとおりです。
Oracle SolarisおよびLinux: X11パイプラインがOracle SolarisおよびLinuxオペレーティング・システムのデフォルトです。
Windows OS - DirectDraw/GDIパイプラインがWindowsのデフォルトです
Windows OS - 全画面モードのDirect3DパイプラインをWindowsでは代替として選択できます。
Oracle Solaris、LinuxおよびWindowsでのOpenGLパイプラインは、Oracle SolarisおよびLinuxオペレーティング・システム、ならびにWindowsでの代替手段です。
UNIXプラットフォームのデフォルト・パイプラインはX11パイプラインです。このパイプラインでは、画面へのレンダリングや、特定タイプのオフスクリーン・イメージ(VolatileImage
など)または「互換性のある」イメージ(GraphicsConfiguration.createCompatibleImage()メソッドで作成されたイメージ)へのレンダリングを行う際に、Xプロトコルが使用されます。
これらのタイプのイメージは、X11ピックスマップ内に格納すればパフォーマンスを改善できます(特にリモートXサーバーの場合)。
さらに、Java 2Dでは特定の場合に、Xサーバー拡張(MIT X共有メモリー拡張、ダイレクト・グラフィックス・アクセス拡張、BufferStrategy
API使用時のダブル・バッファリング用ダブル・バッファ拡張など)が使用されます。
構成によっては、追加パイプラインのOpenGLパイプラインによってパフォーマンスが向上することもあります。
トラブルシューティングの対象となるX11パイプラインのプロパティは次のとおりです。
Java 2Dではデフォルトで、特定タイプのオフスクリーン・イメージの格納やキャッシングにX11ピックスマップが使用されます。
ピックスマップに格納できるイメージのタイプは、次のものだけです。
不透明イメージ(この場合、ColorModel.getTransparency()からTransparency.OPAQUE
が返される)
1ビット透明イメージ(別名「スプライト」、Transparency.BITMASK
)
イメージの格納にピックスマップを使用するメリットは、ドライバの判断でフレーム・バッファのビデオ・メモリー内に配置できる点にあります(そうした場合、これらのピックスマップを画面や別のピックスマップにコピーする際の速度が改善される)。
ピックスマップを使用すれば、通常はパフォーマンスが向上します。ただし、場合によっては逆になることもあります。これらの場合は通常、Xプロトコルを使用して実行できない操作(アンチエイリアス、アルファ合成、単純な移動変換よりも複雑な変換など)が使用されています。
これらの操作については、X11パイプラインは組込みソフトウェア・レンダラを使用してレンダリングを行う必要があります。これにはほとんどの場合、ピックスマップの内容を読み取って(リモートXサーバーの場合はネットワーク経由で)システム・メモリーに格納し、レンダリングを実行した後、それらのピクセルを元のピックスマップに送信するという操作が含まれます。これらの操作ではパフォーマンスが大幅に低下する可能性があります(特にXサーバーがリモートの場合)。
X11パイプラインの使用を無効にする2つの例を次に示します。
X11パイプラインのピックスマップの無効化:
Java2Dでのピックスマップの使用を無効にするには、Java VMに次のプロパティを渡します。-Dsun.java2d.pmoffscreen=false
。
X11パイプラインの共有メモリー・ピックスマップの無効化:
注意:
共有メモリー・ピックスマップは、ローカルXサーバーの場合にのみ使用できます。共有メモリー・ピックスマップを使用するメリットは、X11プロトコルをバイパスしてパイプライン内のピクセルにパイプラインから直接アクセスできる点にあり、その結果、パフォーマンスが向上します。
イメージはデフォルトでは通常のXサーバー・ピックスマップ内に格納されますが、後でそのようなイメージからの過剰な読取りがパイプラインによって検出された場合には、共有メモリー・ピックスマップにイメージを移動できます。イメージのコピー回数が十分な数に達したら、元のサーバー・ピックスマップにイメージを移動できます。
このパイプラインでは、共有メモリー・ピックスマップの使用を制御する方法が2つ用意されています。それらを無効にする方法と、すべてのイメージが共有メモリー・ピックスマップに強制的に格納されるようにする方法です。
共有メモリー・ピックスマップを無効にするには、J2D_PIXMAPS
環境変数をserver
に設定します。これが、リモートXサーバーの場合のデフォルトになります。
すべてのピックスマップが強制的に共有メモリー内に作成されるようにするには、J2D_PIXMAPS
をshared
に設定します。
Java 2DのX11パイプラインはMIT共有メモリー拡張(MIT SHM)を使用しますが、この場合、クライアントとXサーバーの間のデータの交換が速くなります。この機能により、Javaアプリケーションのパフォーマンスが大幅に向上する場合があります。
次は、Javaアプリケーションのパフォーマンスを向上させる2つの方法です。
SPARCハードウェアでは、フレーム・バッファがSunのダイレクト・グラフィックス・アクセス (DGA) Xサーバー拡張をサポートしていて、フレーム・バッファにアクセスするための対応するモジュールがJava 2Dに含まれている場合、画面へのレンダリングにDGAが使用されます。
オフスクリーン・イメージはすべてJavaヒープ・メモリー内に存在しており、それらへのレンダリングにはJava 2Dのソフトウェア専用レンダリング・パイプラインが使用されます。これは、オフスクリーン・イメージにX11ピックスマップが使用される通常のUNIX構成とは異なっています。
次のユースケースは、DGA拡張サポートを検出し、DGAを無効または有効にする方法を説明します。
SPARCプラットフォームの特定のビデオ・ボードでは、複数のビジュアルがXサーバーから使用できます。
Java 2Dはデフォルトで最適なビジュアルを選択しようとしますが、この「最適」というのは通常、ビットの深さがより深いビジュアルを指します。たとえば一部のOracle Solarisオペレーティング・システム・リリースでは、デフォルトX11ビジュアルは8ビット疑似カラーですが、24ビットのビジュアルも使用できます。これらの場合、Java 2Dは、Javaウィンドウのデフォルトとして24ビット・トゥルーカラー・ビジュアルを選択します。
別のビジュアルに対応するGraphicsConfiguration
オブジェクトでJavaトップレベル・ウィンドウを作成することも可能ですが、場合によっては、かわりに別のデフォルト・ビジュアルをJavaに使用させる必要が生じることがあります。これを行うには、FORCEDEFVIS
環境変数を設定します。これは、true
に設定してデフォルトXサーバー・ビジュアルの使用を(たとえ最適でなくても)強制することができる一方で、xdpyinfo
などのツールで報告されたビジュアルIDに対応する16進数に設定することもできます。
Xサーバーのデフォルト・ビジュアルを確認するには、xdpyinfo
コマンドを実行し、default visual id
のフィールドを確認します。
Windowsプラットフォームのデフォルト・パイプラインは、DirectDrawパイプラインとGDIパイプラインを組み合わせたものであり、DirectDrawパイプラインで実行される操作もあれば、GDIパイプラインで実行される操作もあります。高速化されたオフスクリーンやオンスクリーン表面へのレンダリングには、DirectDrawとGDIのAPIが使用されます。
Java SE 6リリース以降では、ドライバが要件を満たしていれば、アプリケーションがフル・スクリーン・モードに入るときに新しいDirect3Dパイプラインを使用できます。Direct3Dパイプラインの問題としては、レンダリング・アーティファクト、クラッシュ、パフォーマンス関連の問題などが考えられます。
構成によっては、追加パイプラインのOpenGLパイプラインによってパフォーマンスが向上することもあります。
次は、レンダリング・アーティファクト、クラッシュ、パフォーマンス関連の問題など、Direct3Dパイプラインの問題のトラブルシューティングを行う3つの例です。
Java SE 6リリース以降のDirect3Dパイプラインでは、レンダリングにDirect3D APIが使用されます。フル・スクリーン・モードではこのパイプラインがデフォルトで有効にされます(ドライバが、必要な機能とそのレンダリング品質レベルをサポートしている場合)。
次の項で説明するように、Direct3Dパイプラインを有効にし、その使用を強制できます。
アルファ合成、アンチエイリアス、変換などのレンダリング操作を大量に使用するアプリケーションでは、Direct3Dパイプラインを有効にすることを検討してください。
ただし、このパイプラインをアプリケーションで有効にすることを決定する際には注意してください。たとえば、一部の組み込みビデオ・チップセット(大部分のノートブックで使用されているもの)は、たとえJava 2Dパイプラインの品質要件を満たしていても、Direct3D使用時には良好なパフォーマンスを示しません。
Direct3D APIの問題のトラブルシューティングを行う3つの例を次に示します。
OpenGLパイプラインは、Oracle Solaris、LinuxおよびWindowsで使用できます。
この代替パイプラインでは、VolatileImage
、BufferStrategy
APIで作成されたバック・バッファ、および画面へのレンダリング時に、ハードウェア高速化されたクロス・プラットフォームのOpenGL APIが使用されます。
このパイプラインはデフォルト(X11またはGDI/DirectDraw)のパイプラインに比べ、特定のアプリケーションでパフォーマンス上の大きな利点を提供できます。アルファ合成、アンチエイリアス、変換などのレンダリング操作を大量に使用するアプリケーションでは、このパイプラインを有効にすることを検討してください。
OpenGLパイプラインの問題のトラブルシューティングを行うユースケースを次に示します
OpenGLパイプラインはデフォルトで無効になっています。
OpenGLパイプラインの有効化を試みるには、次のオプションをJVMに指定します。
-Dsun.java2d.opengl=true
OpenGLパイプラインが特定のスクリーンに対して正常に初期化されたかどうかに関する、詳細なコンソール出力を受け取るには、オプションをTrueに設定します(大文字「T」に注意)。
ハードウェアまたはドライバが最小要件を満たしていなければ、OpenGLパイプラインは有効にされません。
次の要件のいずれかが満たされない場合、Java 2Dはフォール・バックしてデフォルト・パイプライン(Oracle Solaris/LinuxのX11またはWindowsのGDI/DirectDraw)を使用するため、アプリケーションは正しく動作し続けますが、OpenGLの高速化は失われます。
Oracle SolarisおよびLinuxオペレーティング・システムの最低要件を次に示します。
ハードウェア高速化のOpenGL/GLXライブラリがインストールされ、適切に構成されている
OpenGLのバージョンが1.2以降
GLXのバージョンが1.3以降
使用可能な深度バッファ付きの、少なくとも1つのトゥルーカラー・ビジュアル
Windows OSの最小要件は、次のとおりです。
拡張WGL_ARB_pbuffer
、WGL_ARB_render_texture
、およびWGL_ARB_pixel_format
をサポートするハードウェア高速化ドライバ
OpenGLのバージョンが1.2以降
使用可能な深度バッファ付きの、少なくとも1つのピクセル形式
OpenGLベースのJava 2Dパイプラインの起動手順に関する詳細情報を取得するには、J2D_TRACE_LEVEL
環境変数を使用します。
前述したように、特定のマシン上で様々な理由でOpenGLパイプラインが有効にされない場合があります。たとえば、ドライバが正しくインストールされていない可能性や、報告されたバージョン番号が不十分である可能性があります。あるいは、マシンに搭載されている古いグラフィックス・カードがOpenGLの適切なバージョンや拡張をサポートしていない可能性もあります。
Java SE 6以降のリリースでは、次の例に示すように、J2D_TRACE_LEVEL
環境変数を使用してOpenGLベースのJava 2Dパイプラインの起動手順に関する詳細情報を取得できます。
Windowsでは、J2D_TRACE_LEVEL
環境変数を設定します。
# set J2D_TRACE_LEVEL=4 # java -Dsun.java2d.opengl=True YourApp
SolarisおよびLinuxでは、J2D_TRACE_LEVEL
環境変数を設定します。
# export J2D_TRACE_LEVEL=4 # java -Dsun.java2d.opengl=True YourApp
その出力は、プラットフォームや取り付けられたグラフィックス・ハードウェアに応じて異なりますが、OpenGLパイプラインがユーザーの構成で正常に有効にされない理由に関する何らかの洞察を提供してくれます。
注意:
この出力は特に、SunのJava 2Dチーム宛のバグ・レポートを記入する際に特に役立ちます。
レンダリングまたはパフォーマンスの問題の原因がJava 2DまたはOpenGLドライバであるかどうかを診断します。
OpenGLパイプラインはベースとなるグラフィックス・ハードウェアやドライバに非常に強く依存しているため、レンダリングやパフォーマンスの問題の原因がJava 2D、OpenGLドライバのどちらなのかを判定しかねる場合があります。
Java SE 6リリースでのOpenGLパイプラインの新機能の1つは、VolatileImage
使用時のレンダリング・パフォーマンスの改善とVRAM消費量の低減を図るGL_EXT_framebuffer_object
拡張の使用です。この「FBO」コード・パスは、OpenGLパイプラインが有効なときにデフォルトで有効になりますが、それは、グラフィックス・ハードウェアとドライバがこのOpenGL拡張をサポートしている場合に限られます。この拡張は一般に、Nvidia GeForce/Quadro FXシリーズ以降およびATI Radeon 9500以降で使用できます。「FBO」コード・パスがアプリケーションの問題の原因となっている疑いがある場合、次のシステム・プロパティを設定してそれを無効にできます。
-Dsun.java2d.opengl.fbobject=false
このプロパティが設定されると、Java 2Dは古いpbuffer-based
コード・パスにフォール・バックします。
特定のJava 2D操作で得られる視覚的な結果が、OpenGLパイプラインを有効にしたときとしなかったときで異なる場合、それはおそらく、グラフィックス・ドライバのバグを示しています。同様に、OpenGLパイプラインを有効にしたときに、しなかった場合よりもJava 2Dレンダリングのパフォーマンスが大幅に悪化する場合、その原因はおそらくドライバまたはハードウェアの問題です。
どちらの場合も、通常のバグ報告チャネルを通じて詳細なバグ・レポートを提出してください。「バグ・レポートの提出」を参照してください。バグ・レポートの提出時にはできるだけ詳しく記述し、次の情報を含めてください。
J2D_TRACE_LEVEL=4
をコマンド行に指定したときの出力(前の項で説明)glxinfo
コマンドの出力グラフィックス・カードの製造元とそれに対応するWebサイト、サポートされているプラットフォーム、およびカードのいくつかの例のリスト。
OpenGLパイプラインはOpenGL APIおよびベースとなるグラフィックス・ハードウェアやドライバに強く依存しているため、最新のグラフィックス・ドライバがマシンにインストールされているのを確認することが非常に重要です。ドライバは、グラフィックス・カードの製造元のWebサイトからダウンロードできます(次の表を参照)。
製造元 | プラットフォーム | 動作確認済みのカード |
---|---|---|
Linux、Windows |
Radeon 8500以降、FireGLシリーズ |
|
Oracle Solaris on x64、LinuxおよびWindows |
GeForce 2シリーズ以降、Quadro FXシリーズ以降 |
|
Oracle Solaris on SPARC |
Expert3Dシリーズ、XVR-500、XVR-600、XVR-1200、XVR-2500 |
|
Oracle Solaris on x86、Linux |
各種(Xi Graphicsで確認) |