Windowsプラットフォームのデフォルト・パイプラインは、DirectDrawパイプラインとGDIパイプラインを組み合わせたものであり、DirectDrawパイプラインで実行される操作もあれば、GDIパイプラインで実行される操作もあります。高速化されたオフスクリーンやオンスクリーン表面へのレンダリングには、DirectDrawとGDIのAPIが使用されます。
Java SE 6リリース以降では、ドライバが要件を満たしていれば、アプリケーションがフル・スクリーン・モードに入るときに新しいDirect3Dパイプラインを使用できます。Direct3Dパイプラインの問題としては、レンダリング・アーティファクト、クラッシュ、パフォーマンス関連の問題などが考えられます。
構成によっては、追加パイプラインのOpenGLパイプラインによってパフォーマンスが向上することもあります。
次は、レンダリング・アーティファクト、クラッシュ、パフォーマンス関連の問題など、Direct3Dパイプラインの問題のトラブルシューティングを行う3つの例です。
DirectDrawパイプラインの無効化:
DirectDrawが無効になっていると、すべての操作がGDIで行われます。DirectDrawの使用を無効にするには、-Dsun.java2d.noddraw=true
フラグを指定します。この場合、すべてのオフスクリーン・イメージがJavaヒープ内で作成され、それらへのレンダリングにはデフォルトのソフトウェア・パイプラインが使用されます。画面へのオフスクリーン・イメージのコピーだけでなく、オンスクリーンのすべてのレンダリングにもGDIが使用されます。
DirectDrawパイプラインの有効化:
何らかの理由でパイプラインがデフォルトで無効化された場合にそれを有効にするには、-Dsun.java2d.noddraw=false
フラグをVMに指定します。
ただし通常は、そもそも無効にされた理由が存在するので、強制しないほうが得策です。
組込みパント・メカニズムの無効化:
一般に、DirectDrawパイプラインはオフスクリーン表面をフレーム・バッファのビデオ・メモリー内に配置しようとしますが、これにより、それらの表面を画面やほかの高速化された表面にコピーする操作が高速化されるほか、特定のグラフィックス操作のハードウェア高速化レンダリングが可能となります。
VRAMベースの表面への非高速化レンダリングの影響を抑えるために、パント・メカニズムが存在します。このメカニズムでは、頻繁に読み取られると判明した表面をシステム・メモリーに移動します。頻繁にコピーされると判明した表面は、ビデオ・メモリーに戻すよう促されることがあります。
ただし、パイプラインがDirectDraw APIを使って実行できない操作(アルファ合成、変換、アンチエイリアスなどを使用する操作)については、ソフトウェア・パイプラインを使ってレンダリングが実行されます。これは場合によっては、VRAM内に存在する宛先表面のピクセルを読み取ってシステム・メモリーに格納する必要があることを意味しますが、それは非常にコストの高い操作です。
特定のビデオ・ボード/ドライバの組み合わせでは、システム・メモリー・ベースのDirectDraw表面がレンダリング・アーティファクトやその他の問題の原因となることが知られています。DirectDrawパイプラインには、システム・メモリー表面が使用されないようにパント・メカニズムを無効にするための方法が用意されています。
組込み表面パント・メカニズムを無効にするには、Java VMに-Dsun.java2d.ddforcevram=true
フラグを指定します。
注: これにより、パフォーマンスが低下することがあります。操作のたびにソフトウェア・ループによってVRAMからピクセルが読み取られる可能性があるためです。この場合は、DirectDrawパイプライン(上記参照)の無効化を検討することができます。 |
DirectDraw BILT操作の無効化:
BILT操作(Bit Block Transfer)では2つのビットマップ・パターンが合成されます。この操作は基本的に、Graphics.drawImage()
APIの呼出しに対応します。
場合によっては、DirectDraw Blit操作を無効にすることでレンダリングの問題を回避できます。代わりにGDI Blitが使用されます。注意: これによってパフォーマンスが低下する場合があります。代わりにDirectDrawパイプラインの無効化を検討してください。
DirectDraw Blit操作の使用を無効にするには、パラメータ-Dsun.java2d.ddblit=false
をJava VMに渡します。