12.1 一般的なパフォーマンス問題

12.1.2 非高速化レンダリングの検出および回避のためのプリミティブ・トレース

高速化されないレンダリングを検出するには、Java 2Dプリミティブ・トレースを使用できます。

Java 2Dには組込みのプリミティブ・トレースが含まれています。「Java 2Dテクノロジのシステム・プロパティ」のtraceプロパティの説明を参照してください。

アプリケーションの実行時に-Dsun.java2d.trace=countを指定します。アプリケーションが終了すると、プリミティブのリストとそれらのカウントがコンソールに出力されます。

MaskBlitプリミティブや任意のGeneral*プリミティブが表示された場合、それは通常、レンダリングの一部がソフトウェア・ループによって処理されていることを意味します。Linux上で、半透明のBufferedImageに対してdrawImageを実行してVolatileImageに書き込む場合の出力を、次に示します。

sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, "Integer BGR Pixmap")sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntBgr)

デフォルト・パイプラインでの一般的な非高速化プリミティブと、トレース出力に示されるそれらの特徴をいくつかあげてみます。注意: このトレースのほとんどはLinuxで行われたものです。使用しているプラットフォームや構成によっては多少の違いが生じる可能性があります。

• 半透明イメージ(ColorModel.getTranslucency()でTranslucency.TRANSLUCENTが返されるイメージ)、またはAlphaCompositingを使用したもの。サンプルのプリミティブ・トレース出力:

  sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb,SrcOverNoEa, "Integer BGR Pixmap")sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntBgr)
  

• アンチエイリアスの使用(アンチエイリアス・ヒントの設定による)。サンプルのプリミティブ・トレース出力:

  sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntBgr)
  

• アンチエイリアス・テキストのレンダリング(テキスト・アンチエイリアス・ヒントの設定)。サンプル出力は次のいずれかになります。

  • sun.java2d.loops.DrawGlyphListAA::DrawGlyphListAA(OpaqueColor, SrcNoEa, AnyInt)
    

  • sun.java2d.loops.DrawGlyphListLCD::DrawGlyphListLCD(AnyColor, SrcNoEa, IntBgr)
    

• アルファ合成(半透明カラー(0xff以外のアルファ値を含むカラー)でのレンダリング、Graphics2D.setComposite()によるデフォルト以外のAlphaCompositingモードの設定、のいずれかによる)。

  sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOver, IntRgb)sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb)
  

• 本格的な変換(単なる移動ではない変換)。変換された不透明イメージのVolatileImageへのレンダリング。

  sun.java2d.loops.TransformHelper::TransformHelper(IntBgr, SrcNoEa, IntArgbPre)
  

• 回転されるラインのレンダリング。

  sun.java2d.loops.DrawPath::DrawPath(AnyColor, SrcNoEa, AnyInt)
  

アプリケーションをトレース付きで実行し、不要な非高速化プリミティブを使用していないことを確認してください。

12.1.3 低いレンダリング・パフォーマンスの原因

いくつかのレンダリング・パフォーマンスの低下の原因および可能な選択肢を次に示します。

• 高速化レンダリングと非高速化レンダリングの混在:

  特定のパイプラインでの高速化表面へのレンダリング時に、アプリケーションによってレンダリングされるプリミティブの一部しか高速化できない状況では、スラッシングが発生する可能性があります。パイプラインで常にレンダリング・パフォーマンスの改善に向けた調整が試行されても、成功する可能性がおそらくほとんどないからです。

  レンダリング・プリミティブの大部分が高速化されないことが事前にわかっている場合、BufferedImageにレンダリングしてからバック・バッファや画面にコピーするか、あるいは前述のフラグのいずれかを使って非ハードウェア高速化パイプラインに切り替えたほうが得策です。

  
  

  注: このアプローチを採用した場合、Java 2Dでのハードウェア高速化の使用状況が将来改善されても、そのメリットをアプリケーションで享受できなくなる可能性があります。

  
  

  たとえば、リモートXサーバー・ケースでの使用頻度の高いアプリケーション内でアンチエイリアスやアルファ合成などが多用されると、パフォーマンスが極度に低下する可能性があります。これを避けるには、-Dsun.java2d.pmoffscreen=falseプロパティをJavaランタイムに渡すかプログラム内でSystem.setProperty() APIを使って設定して、ピックスマップの使用を無効にします。注意: このプロパティは一度だけ読み込まれるので、GUI関連の操作の前に設定する必要があります。

• 最適でないレンダリング・プリミティブの使用:

  目的の視覚効果を実現する際に、可能なかぎりもっとも単純なプリミティブを使用することをお薦めします。

  たとえば、Graphics.drawLine()を使用して新しいLine2D().draw()は使用しません。結果は同じようにみえます。ただし、2番目の操作では、通常レンダリング・コストの非常に高い汎用形状としてレンダリングされるため、計算量が格段に多くなります。形状は、プリミティブ・トレース内で、アンチエイリアス設定や特定のパイプラインに応じてさまざまな方法で表示されますが、おそらく多数の*FillSpansまたはDrawPathプリミティブとして表示されます。

  複雑な属性のもう1つの例は、GradientPaintです。これは、デフォルト以外の一部のパイプライン(OpenGLなど)ではハードウェア高速化される可能性がありますが、デフォルト・パイプラインではハードウェア高速化されません。したがって、パフォーマンスの問題が発生する場合にGradientPaintの使用を制限できます。

• ヒープに基づく出力先のBufferedImage:

  BufferedImageへのレンダリングでは、ほとんど常にソフトウェア・ループが使用されます。

  一部のSPARCシステムでの例外は、特定のイメージング操作を高速化するためにVIS命令セットが使用される場合があることです。VIS命令セットを参照してください。

  レンダリングが高速化される機会を残すには、BufferStrategyまたはVolatileImageオブジェクトをレンダリング先として選択してください。

• 組込み高速化メカニズムの無効化:

  Java 2Dは特定タイプのイメージを高速化しようとします。VolatileImageなどの高速化宛先へのコピーを高速化するため、イメージの内容がビデオ・メモリーにキャッシュされる可能性があります。これらのメカニズムは、意図せずにアプリケーションで無効化される場合があります。

• getDataBuffer()によるピクセルへの直接アクセス:

  アプリケーションがgetRaster().getDataBuffer() APIを使ってBufferedImageピクセルにアクセスした場合、Java 2Dは、キャッシュ内のデータが最新であることを保証できないため、そのようなイメージの高速化の試みをすべて無効にします。

  これを回避するには、getDataBuffer()を呼び出さないでください。代わりに、BufferedImage.getRaster()メソッドで取得可能なWriteableRasterを操作します。

  ピクセルを直接変更する必要がない場合には、イメージをビデオ・メモリー内に手動でキャッシュするためにイメージのキャッシュ・コピーをVolatileImage内に保持し、元のイメージが更新された時点でそのキャッシュ・データを更新します。

• すべてのコピーの前のスプライト・レンダリング:

  アプリケーションがイメージを高速化表面(VolatileImage、BufferStrategy)にコピーする前にイメージに毎回レンダリングする場合、そのイメージは、高速化メモリーにキャッシュされるメリットを享受できません。その理由は、元のイメージが更新されるたびにキャッシュ・コピーを更新する必要があり、そのためにデフォルトのシステム・メモリー・ベースの表面だけが使用されて、高速化されないからです。

• 高速化メモリー・リソースの枯渇:

  アプリケーションが多数のイメージを使用すると、使用可能な高速化メモリーが使い果たされる可能性があります。これが本当にアプリケーションのパフォーマンス問題の原因となっている場合、リソースを管理しなければいけない可能性があります。

  次のAPIを使えば、使用可能な高速化メモリーの量を要求できます。GraphicsDevice.getAvailableAcceleratedMemory()。

  さらに次のAPIを使えば、イメージが高速化されているかどうかを判定できます。Image.getCapabilities()。

  アプリケーションがリソースを使い果たしていると判断した場合は、必要のないイメージを保持しないことにより、問題を処理できます。たとえば、ゲームが次のレベルに進んだら、以前のレベルに含まれるイメージをすべて解放します。また、イメージに関連付けられた高速化リソースをImage.flush() APIで解放することもできます。

  高速化優先度API Image.getAccelerationPriority()およびsetAccelerationPriority()を使用してイメージの高速化優先度を指定することもできます。少なくともバック・バッファを高速化することは妥当なので、これを最初に作成し、高速化優先度1 (デフォルト)を指定します。また、必要であれば、高速化優先度を0.0に設定して、特定のイメージが高速化されないようにすることもできます。

Copyright © 1993, 2020, Oracle and/or its affiliates. All rights reserved.

連絡先