カスタムpaintComponent()実装を備えたJPanelサブクラスがあります。50fpsで更新されています。通常、サイズは500x300ピクセルの範囲です。ちらつきが見られ(それほど悪くはありませんが目立ちます)、Swing / EDTが(おそらく)冗長なペイントをスキップしていることを示すデバッグコードを挿入しました。これは、EDTがpaintComponent()を常に終了するのに十分な時間を与えていないか、EDTで時間がかかりすぎているためだと思います。
私の考えでは、現在paintComponent()を実装しているコード(それほど複雑ではありませんが、完全に簡単ではありません)をリファクタリングして、独自のスレッド(または少なくともEDTではない)で実行され、 ImageBuffer。次に、カスタムJPanelにpaintComponentを実装し、ImageBufferから画面に描画(レンダリング)します(実際には、ソリューションの調査により、Swingが(デフォルトで)ダブルバッファーになっているという情報が得られたため、Swingコンポーネントの背後にあるバッファーに描画します。それについては完全には明確ではありません)。ImageBufferからJPanelへのレンダリングが、ImageBufferを構築する私の実装よりも速いことが事実である場合、私は正しい方向に進んでいます。
これは私にとって適切な設計の方向性ですか?
アップデート
以下の回答で説明されているように、実装を変更しました。
1)BufferedImageを作成します
BufferedImage myBufferedImage = new BufferedImage(mySize.width,mySize.height,BufferedImage.TYPE_INT_ARGB)
2)何を描画するかを決定するために、処理の実行専用のスレッドを作成します。
3)以前にpaintComponent()にあったコードを、専用のスレッドによって実行される別のメソッドに移動します。このメソッドの最後に、repaint();を呼び出します。
4)単に呼び出す新しいpaintComponent()を作成しますg.drawImage(myBufferedImage,0,0,null);
5)以前はrepaint()を呼び出していた場所で、myThreadをトリガーしてmyBufferedImageへの描画を実行します。
予想通り、これは災害でした。ちらつきや動きの鈍さ、部分的なペイントなどがさらに悪化しました。これは、myBufferedImageの読み取り/書き込みの競合が原因であると考えられます(以下で説明します)。そこで、(専用の描画スレッドで)書き込み中にmyBufferedImageをロックしてロックし、graphs2D.drawImage()を呼び出す前にpaintComponent()でそのロックを取得するのを待ちます。ちらつきや部分的なペイントはなくなりますが、paintComponent(したがってEDT)で描画のすべての計算を行ったときよりも、パフォーマンスは良くなりません(おそらくさらに悪くなります)。
これは私がこの時点で困惑しています。