ダブルバッファリングしたら重くなりました

Question

Swingを使って２Dスクロールゲームを作るときに、ダブルバッファリングを実装したのですが、バッファイメージのサイズを大きくすると動きが遅くなってしまいました。以下はその詳細です。何か分かることがございましたら、アドバイスをお願いします。

#ダブルバッファリング実装方法
※クラス[変数名]
・JFrameにおいてインスタンス生成時に、createImage(this.getWidth(), this.getHeight())でバッファイメージImage[back]とback.getGraphics()でそのグラフィクスGraphics[buffer]を変数として取得しておく。
・paint(Graphics g)をオーバーライドしてbufferに描画して、最後に**graphics.drawImage(back, 0, 0, this)**でバッファイメージを描画する。
・componentResizedをオーバーライドしてImage[back]とGraphics[buffer]を変更（更新）する。
・update(Graphics g)はオーバーライドしていない。

#問題点
・実行してみて、画面を大きくすると動きが遅くなることに気がついた。
・フレームレートを測定すると、画面の大きさに比例して時間が遅くなっていた。
・試しに、**graphics.drawImage(back, 0, 0, this）**だけをコメントアウトすると画面は変わらないが、フレームレートは速くなった。
・試しに、**paint(Graphics g)において、先頭でbuffer = g;を書くと（ダブルバッファリングしないようにすると）ちらつくが速くなった。
・試しに、インスタンス生成時にcreateImage(2000, 2000)**とするとずっと遅くなった。

#修正（該当のコード）

package orgmarigo.test;

import javax.swing.*;
import java.awt.Graphics;
import java.awt.Image;
import java.awt.event.*;

import orgmarigo.util.Vector2;
import orgmarigo.util.TimeMeasure;//フレームレートを測定するクラス
import orgmarigo.util.MyUtilities;

public class ScreenTest extends JFrame implements ActionListener, ComponentListener{
  static public final Vector2 INITIAL_WINDOW_SIZE = new Vector2(630, 560);
  static public TimeMeasure timeMeasure = new TimeMeasure(100);
  static public final int FPS = 100;

  private Timer timer;
  private Image back;
  private Graphics buffer;
  private Image titleImage;

  public static void main(String[] args) {
    new ScreenTest();
  }

  public ScreenTest(){
    this.setTitle("ScreenTest");
    this.setBounds(300, 200, (int)INITIAL_WINDOW_SIZE.getX(), (int)INITIAL_WINDOW_SIZE.getY());
    this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

    this.addComponentListener(this);

    this.setVisible(true);

    timer = new Timer(1000 / FPS, this);
    back = createImage(this.getWidth(), this.getHeight());//バッファイメージ
    buffer = back.getGraphics();//イメージのグラフィクス
    titleImage = MyUtilities.getImage("../images/title/TitleImage.jpg");

    timer.start();
  }

  @Override
  public void paint(Graphics graphics){
    if(buffer != null){
      //イメージの更新、描画
      buffer.clearRect(0, 0, this.getWidth(), this.getHeight());
      buffer.drawImage(titleImage, 0, 0, this.getWidth(), this.getHeight(), null);
    }

    graphics.drawImage(back, 0, 0, this);
  }

  @Override
  public void actionPerformed(ActionEvent e){
    Object source = e.getSource();

    if(source == timer){
      timeMeasure.Update();
      repaint();//再描画
    }
  }

  @Override
	public void componentHidden(ComponentEvent e) {}

	@Override
	public void componentMoved(ComponentEvent e) {}

	@Override//リサイズしたとき
	public void componentResized(ComponentEvent e) {
    back = createImage(this.getWidth(), this.getHeight());
    buffer = back.getGraphics();
  }

	@Override
	public void componentShown(ComponentEvent e) {}
}

#その他
・ネットで調べて、setDoubleBuffered(boolean)を見つけたが使い方がわからなかった。

Answer 1

ダブルバッファの目的は、ユーザビリティの向上であり、データを集めている間にすでに集まっているデータを利用して処理をすることで、ユーザの応答性が向上することが主な目的になります。並行して処理を行うことにより返って処理が重くなることはあり得る問題です。

画面を大きくすると動きが遅くなる

画面サイズによりということは、例えば画素単位での処理がある場合に処理が増大したりしますし、バッファサイズに影響を与えている可能性もあります。

画面の大きさに比例して時間が遅くなっていた

これも一フレームあたりの処理が遅くなるためでしょう。

graphics.drawImage(back, 0, 0, this）だけをコメントアウトすると画面は変わらないが、フレームレートは速くなった

drawImage自体は描画を行うが、画像サイズに比例して描画時間が増大することは考えられなくは無いですね。

ですので、一画面の処理をある程度高速化するなりしないと改善が難しいと思いますし、それをするためには、その処理のパフォーマンス測定、プロファイルが必要かと思います。
また、その速度が十分に高速になれば、ダブルバッファも不要になるかもしれません。

Answer 2

実メモリー不足では?
実装されているメモリーに対し、アプリが使用するメモリー量が多すぎると、ページングと言ってその時点で使用していないメモリーの一部を一時的にディスクに書き出して実メモリー不足を補って処理します。
これが多発すると処理速度が目に見えて落ちます。
ダブルバッファーとすることでメモリー不足が発生している可能性があります。
メモリー量(実装量と、アプリが動作する前の時点でのOS等の使用量、アプリの使用量)を確認してください。

Answer 3

バッファイメージのサイズを大きくすると動きが遅くなってしまいました。

ダブルバッファリングも"処理"ですから, 対象が多くなれば遅くなるのは当然かと思います.
ダブルバッファリングのコードの問題とお考えであれば, 「JFrameにおいてインスタンス生成時に～」という日本語説明で無く, コードをご提示ください.

setDoubleBuffered(boolean)を見つけた

Swing はコンポーネントの描画の為にダブルバッファリングを(うろ覚えですが) JComponent のレベルで実装・実行しています.
ただ個々のコンポーネントがダブルバッファリングしても意味はありませんので, 個々のコンポーネントのデフォルトは Off となっており, JFrame の ContentPane のレベルが On になっています.
その On/Off を設定するためのメソッドが setDoubleBuffered だったと思います.

Comments

[rimokonTenko_mo]

コードは、どう言う形で提示すればよいでしょうか。

質問に関係のある処理以外にもいろいろな処理が書かれていて、ファイル全体を提示すればよいのか、あるいは必要な部分だけ切り取って提示すればよいのか分かりません。

[jimbe]

可能であれば全体が良いですが, 推奨最低条件は「コンパイルして状況が再現できる」コードです.

[rimokonTenko_mo]

再現するのに少し時間がかかってしまいましたが、コードを提示しました。よろしくおねがいします。

[jimbe]

orgmarigo.util.* や大きな jpeg が必要なので試せませんが, このコードはダブルバッファリングがどうこうというよりは, 単にベタ画像を書くのにどれだけ時間が掛かるかというだけではないでしょうか.
ダブルバッファリングの一番の目的は, 消したり書いたりによるちらつきを無くすことです.
バッファ(メモリ領域)を用いたりバッファへの書き込み→画面への書き込みという段階を踏んだりの余計な資源・時間を使うこととのトレードオフでダブルバッファリングを行うか否かを判断すべきで, つまりちらついても早いほうが良いか, 遅くてもちらつかないほうが良いかです.
もし画面のほとんどが時間が経っても変わらず, フレーム毎のバッファへの更新範囲が少ないなら, バッファから画面への描画も更新範囲のみに最適化することで高速化は出来ますが, ご提示のコードではそれが出来るかは分かりません.
２Dスクロールゲームということですので, ゲーム中は背景全体がスクロールしているとしたら, 部分更新による高速化は出来ないかもしれませんので, 「遅くてもちらつかない」ということで仕方ないとするしかないかもしれません.

[rimokonTenko_mo]

分かりました。最初は、paint関数の引数も、バッファイメージも同じGraphicsなのに、なぜ遅くなるんだろうと思っていたのですが、２つのGraphicsは何か違うみたいですね。問題の「重くなった」のは、ダブルバッファリングの「代価」ということですか。エラーみたいに何かを追加したり、文法が間違っているといった問題ではなく、仕方がないものであるということがわかって、良かったです。ウィンドウのサイズを固定化するなどして対応してみます。

[jimbe]

> paint関数の引数も、バッファイメージも同じGraphicsなのに、なぜ遅くなるんだろうと思っていた
同じなのは「出来ることが同じ」だからで, 作用する先が違うということです.
同じペンを使っても, 役所への提出資料にも広告の裏にも書けるのと同じです.
ダブルバッファリングにつきましては多数情報があると思いますので, 再度確認・調査されたらと思います.

[rimokonTenko_mo]

丁寧に教えていただき、ありがとうございました