描画時の画面のちらつき

[k.yo...@chime.ocn.ne.jp]

お世話になっております。木下です。

SurfaceViewにイメージを転送することで擬似的にアニメーションを
行っています。

このときに画面のちらつきが気になります。
（あまりにもイメージの転送が多いためだと思います）

８オクターブ３和音なのですけれど、
要はA♭～A～A#～Bのように、決まったところでアニメーションを
停止させたいので3gpにしたような場合にdurationがまちまちになるのを
防ぐために、このような仕様としました。
（つまり、3gpにせよアニメーションの素材を作る人は別で
なおかつ上記のように決まった音のところで停止をさせる必要があり
ロジック上停止位置は一音当たり7*3*8通りです）

当然、A♭～Aへ移行するときの変化のステップを減らせば
イメージの転送回数は減りますから、ちらつきは減りそうです。

ただ、根本的解決にはならないように思うのです。

お知恵を拝借できますでしょうか？

よろしくお願いします。

[Keiji Ariyama]

有山です。

　SurfaceViewはそのまま使うとチラつきはあまり気にならないはずなのです
が、、、ソースを拝見しないと細かいことはわかりませんが、１フレームごとに
Canvasの塗りつぶし処理をしているということはありませんか？

　SurfaceView(Holder)は、ダブルバッファリングを自動で行います。一気に
lockCanvasで取得したCanvasオブジェクトに、描画してから
unlockCanvasAndPostをするようにしてみてはどうでしょうか。
　
有山圭二

--
Keiji,
ml_an...@c-lis.co.jp

[k.yo...@chime.ocn.ne.jp]

ご返信ありがとうございます。

ダブルバファを自動的にしてくれているのですね。
塗りつぶし処理などは行っていませんから、
転送イメージの領域が大きいことも問題なのでしょう。
（３和音のイメージ転送領域は全画面の2/3程度あります）
HVGAの場合だと、今あるイメージのサイズは一音に月
70x70pixで一音当たり３つの大きさですから
70x270pix これを３つ廻しています。

----- 元のメッセージ -----
From: "Keiji Ariyama" <ml_an...@c-lis.co.jp>
To: android-...@googlegroups.com
送信済み: 2011年1月30日, 日曜日 午前 12:45:20 GMT+09:00日本
件名: Re: [Android-SDK-Japan:1316] 描画時の画面のちらつき

[Keiji Ariyama]

有山です。

　現時点では、大きな画像で描画は遅くなるかもしれないけど、チラつきは出る
かなぁ。というのが正直なところです。イメージ描画スレッドのコードは載せら
れますか？

--
Keiji,
ml_an...@c-lis.co.jp

[たろサ]

　こんにちは、はじめまして、たろサです。

　ソースを見ないと何とも言えませんが、"SurfaceView"と"ちらつき"のキー
ワードから考えるに、ダブルバッファの使い方を間違っているとかありませんで
しょうか。

　ダブルバッファなので、バッファの2画面が交互に表示されたときに、表示画
面の連続性を保つようにしないと、画面はちらつきます。
　例えば、画面に'A'と'B'が表示されているとして、'A'を移動させて、次の画
面で'B'を移動させるとかしてしまうと、動かしたはずの'A'はこの画面では動い
ていないので、'B'だけ動いて、'A'は元いた場所に戻っている画面になります。

　なので、SurfaceViewを使って、連続的に何かを動かすときには、動いた場合
は、少なくとも二回連続して描くか、何も考えずに、常に画面のアイテムを全て
書き直す必要があります。
　全画面を書き直すのが嫌で、ほんの一部だけ動かしたいような場合は、同じア
ニメーションを両バッファ画面に書いても、ちらつきはなくなるはずです。

　フレームレートが確保できているのであれば、どっちでもいいかなと思いま
す。あくまでも、ソースがわからないので、想像で書いています。違っていたら
スルーしてください。

--
山本三七男 (Minao Yamamoto) ---------------- ハンドル:たろサ -----
E-Mail: taro...@gmail.com

[k.yo...@chime.ocn.ne.jp]

お世話になります。

描画部分は
protected void drawNots(Canvas c, SurfaceHolder holder) {
for (int i = 0; i < numNotes; i++) {
int x1 = 0;
int y1 = noteY[i];
int x2 = noteImageWidth;
int y2 = notedDisplayHeight + noteY[i];
Rect src = new Rect (x1,y1,x2,y2);

c.drawBitmap (noteImgs[i], src, destRects[i], null);
}
}

呼び出し元では
Canvas c = holder.lockCanvas();
drawNotes(c, holder);
holder.unlockCanvasAndPost(c);

としています。

----- 元のメッセージ -----
From: "たろサ" <taro...@gmail.com>
To: android-...@googlegroups.com
送信済み: 2011年1月30日, 日曜日 午後 5:42:49 GMT+09:00日本
件名: Re: [Android-SDK-Japan:1319] 描画時の画面のちらつき

　こんにちは、はじめまして、たろサです。

--
このメールは Google グループのグループ「Android-SDK-Japan」の登録者に送られています。
このグループに投稿するには、android-...@googlegroups.com にメールを送信してください。
このグループから退会するには、android-sdk-ja...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/android-sdk-japan?hl=ja からこのグループにアクセスしてください。

[Keiji Ariyama]

有山です。

　クラスメンバnumNotesは、最大でどれくらいの大きさですか？
　for文の中でnew Rectをしているのは、ループの外に置いた方がいいと思いま
すが、いかがでしょうか。

private final Rect mSrc = new Rect();

protected void drawNots(Canvas c, SurfaceHolder holder) {
for (int i = 0; i< numNotes; i++) {

mSrc.top = noteY[i];
mSrc.right = noteImageWidth;
mSrc.bottom = notedDisplayHeight + noteY[i];
c.drawBitmap (noteImgs[i], mSrc, destRects[i], null);
}
}

　あと、drawNotsメソッドの呼び出し元はスレッドですか？優先順位はどのよう
に設定していますか？
　スレッドの中で繰り返し描画をしていると思いますが、繰り返し間隔はどれく
らいを設定していますか？

有山　圭二

--
Keiji,
ml_an...@c-lis.co.jp

[たろサ]

　こんにちは。

　drawNots()で、SurfaceViewの画面をクリアしていないので、2画面前の画像が
残っているんじゃないかなぁ・・・。

　呼び出し元を、下記のようにして無理繰り2バッファ描いちゃうという荒業で
どうかな(^^;。

Canvas c = holder.lockCanvas();
drawNotes(c, holder);
holder.unlockCanvasAndPost(c);
c = holder.lockCanvas();
drawNotes(c, holder);
holder.unlockCanvasAndPost(c);

[egg]

木下さん

江川と申します。
現時点でどれくらいのフレームレートが出ているかによりますが、
たろサさんが最初のメールでおっしゃっていたように、画面全体を描いてみてはいかがでしょうか。
（今回のケースでは、Notesを描く前に背景も描く。）
また、もしかすると既に実装されているかもしれませんが、
アニメーションさせているとすれば、フレームレートが一定になるように
onDrawの呼び出し間隔を調整したほうが端末のスペックに依らず
動くのでよいかもしれません。

------------------------------------------
EGAWA Takashi

2011/2/2 たろサ <taro...@gmail.com>:

[k.yo...@chime.ocn.ne.jp]

有山さん
たろサさん
江川さん

ありがとうございます。明日に試してみようと思います。
現在別のスレッドから呼び出しをしています。
３和音で試していますので、三つが動く形です。
88width * 440height です。これが三つです。

ただその修正の前に別スレッドからholder.lockCanvas();
を呼び出したときに永遠とnullを変えし続けることがあると指摘されたことです。

基本的つくりは
NoteApp NoteView
-> create
setContentView
-> startAnimation
-> create AnimationThread

基本が多分できてないんでしょう。私。

[egg]

> 現在別のスレッドから呼び出しをしています。
> ３和音で試していますので、三つが動く形です。

もしかして３つのスレッドから描いていますか？
SurfaceViewで別スレッド（今回で言うAnimationThread）を使って描画させることはOKですが、ある時点で
Canvasに描けるのは1つのスレッドだけです。
lockCanvasが成功した（nullじゃなかった）スレッドだけがunlockCanvasAndPostまでの間描くことができます。
そのため、スレッドを３つに増やしても高速にはならないでしょうし、各々のスレッドで毎回全画面を描いて
いるのなら、ちらついたり、アニメーションが不連続になりうるでしょうね。
描画のスレッドは1本にして、そこで３つのオブジェクト全部（＋背景）を描くようにしてみて下さい。

------------------------------------------
EGAWA Takashi

2011/2/2 <k.yo...@chime.ocn.ne.jp>:

[Keiji Ariyama]

有山です。

　ようやく全体像がわかって気がしますが、これっていくつかの画像が、１つの
画面上で同時に動いている（表示している）ように見せたいってことですね。

　江川さんの仰るように、描画スレッドを１つ作って、そのスレッドの中では音
符をSurfaceViewに描画するだけにする。
　３つのスレッドは、それぞれの音符の位置情報（動いているのなら）を計算す
るだけで、描画は行わない。

　と、役割を分担すれば、チラつきはなくなると思います。

--
Keiji,
ml_an...@c-lis.co.jp

[たろサ]

　たろサです。

　こんにちは。私も同意見です。

　描画スレッドを別に1スレッド作ったほうがいいと思います。

　あと、やっぱり、for (int i = 0; i < numNotes; i++)する前に背景を描いて
いない(前々回の画面を消していない)のが気になります。

　また、c=nullでdrawNotes()を呼び出しても、 c.drawBitmap()でエラーになる
はずなので、どこかでエラートラップかnullトラップをやっていて、そこらへん
が原因を見つけづらくしているのかも知れませんね。

　

--

[k.yo...@chime.ocn.ne.jp]

江川さん
有山さん
たろサさん

ご指摘ありがとうございます。
描画スレッドは一つなのですけれど、確かに背景を書いていません。

while (running) {
Thread.yield();
Canvas c = null;
try {
c = holder.lockCanvas();
if (c != null) {
synchronized (LOCK) {
drawNotes(c, holder);
moveNotes();
}
}
} finally {
if (c != null) {
holder.unlockCanvasAndPost(c);
}
}

とりあえず、この変更を致しました。
背景描画と位置の計算は明日試してみます。

変更したのは finally句の追加です。（月面着陸でこうしていました。そして背景の描画も行っていました）
確かにRuntimeExceptionが投げられることもあるのでしょう。

ありがとうございます。

----- 元のメッセージ -----
From: "たろサ" <taro...@gmail.com>
To: android-...@googlegroups.com

送信済み: 2011年2月3日, 木曜日 午後 2:43:11 GMT+09:00日本
件名: Re: [Android-SDK-Japan:1340] 描画時の画面のちらつき

[k.yo...@chime.ocn.ne.jp]

背景を描画するようにしたところ、ちらつきが無くなりました。
描画範囲が広いにもかかわらず、ちらつきが減るというのは、
初心者のためか理由が分からないことでもあります。

各ノートの移動の計算は、確かに機種に依存するでしょうから、
上手にコントロールをする方法を模索中です。
（数学が苦手なのです）

多分、座標位置計算スレッドがどのくらいの頻度で呼ばれて、
各音のイメージを廻す回数は毎秒何回、とかで差分を取っていけば
何とかなるような気がするのですけれど、
何か公式のような物をご存じの方がいらっしゃれば教えて下さい。

ありがとうございます。

----- 元のメッセージ -----
From: "k yoriko" <k.yo...@chime.ocn.ne.jp>
To: android-...@googlegroups.com
送信済み: 2011年2月3日, 木曜日 午後 11:13:25 GMT+09:00日本
件名: Re: [Android-SDK-Japan:1341] 描画時の画面のちらつき

[egg]

> 描画範囲が広いにもかかわらず、ちらつきが減るというのは、
> 初心者のためか理由が分からないことでもあります。

描画の速度が今回のちらつきの原因ではなかったという事だと思います。

> 多分、座標位置計算スレッドがどのくらいの頻度で呼ばれて、
> 各音のイメージを廻す回数は毎秒何回、とかで差分を取っていけば
> 何とかなるような気がするのですけれど、

色々方法が考えられますが、木下さんのおっしゃる考え方で実現できると思います。
期待するフレームレートを決めて、例えば50fpsなら、毎フレーム20ミリ秒かけて描けばよいので
onDrawの呼び出しの最初と最後の時刻を記録して、20ミリ秒かかっていないようなら次の描画を
遅らせるような実装が考えられます。（15ミリ秒で描き終わっていたら5ミリ秒ほど待つ）
逆に間に合わないようなら、描くものを減らしたりするような工夫を入れる余地もあるかもしれません。
Androidに限らずゲームプログラミングではこのあたりは一般的に行われていることだと
思いますので、ゲームプログラミング系の情報を探せば参考になるものが見つかると思います。

------------------------------------------
EGAWA Takashi

2011/2/4 <k.yo...@chime.ocn.ne.jp>:

[たろサ]

　たろサです。

　ちらつきが無くなってよかったです。

> 描画範囲が広いにもかかわらず、ちらつきが減るというのは、
> 初心者のためか理由が分からないことでもあります。

　たぶん、私の最初の危惧が当たっていたのだと思います。ダブルバッファが
行っていることの理解ですね。

> 各ノートの移動の計算は、確かに機種に依存するでしょうから、
> 上手にコントロールをする方法を模索中です。

　私もAndroid & java暦 4ヶ月ほどなので、それほどわかっていないですが、基
準カウンタか何か動かして、そのカウンタを見ながら全てを動かすとか、そんな
感じじゃ駄目ですかね？

　ではでは。