はじめてのにき

_ ゴルフ会

http://partake.in/events/ca7e323a-7dff-4f60-86af-d20cd30555bb

適当に御参集おねがいします

(01:39)

_ 最近なんだかなーと思ったバグ

if (foobar) {
  LOG(ERROR) << "foobar";
  return;
}

if (barbaz)
  LOG(ERROR) << "barbaz";
  return;

if (hogefuga) {
  LOG(ERROR) << "hogefuga";
  return;
}

doSomething();

とかやってて、 doSomething 呼ばれねーなでもエラーメッセージも出てないななんでだ…とかしばらく考えてしまった。 Python 使うべきか

(01:41)

_ 最近なんだかなーと思ったバグ2

ひき続きぼんやりとぷよぷよをやってて、オレオレシミュレータが欲しいな…とか思って適当に書いてた。

JS で書いてて、 linux chrome で試してたんだけど、 android chrome の方の動作が遅すぎるなーとか思って、ちょっと描画まわりをいじってみたりすると速くなった気がする。

でもなんかやっぱり遅い気がする。というか動かしてるうちにだんだんと遅くなっている気がする。描画まわりをいじって速くなった気がしたのは、リロードして速い状態に戻っただけな気がする。 linux chrome では遅くならないのにナゼ…という。 FPS カウンタを入れてみると、やはりみるみるうちに FPS が減っていく

となるとどんどんデカくなってる配列があるとかかな、でも linux chrome では遅くならんしなーと思いつつデータ見てみるも、そんなのはない。そのうちに android chrome の方だと動かす前の画面で放置しててもだんだん遅くなっていくということに気付く。

はてなんでだろう…お行儀の描画 API の使いたしてて、 android chrome の WebKit はそれが秘孔をつくとかかなーとか思いつつ #sdl-fan-jp でフッシギーとか言ってみる。したら firefox と mac chrome でも遅くなっていくと報告していただく。 win chrome は大丈夫。 firefox については自分でも確認できた。

となるとむしろ linux chrome だけがお行儀が悪いことを許してると考えた方が自然かなーと思う。 chrome の挙動の違いも、どっちかというと最近の WebKit だと大丈夫、って感じかなぁとか思う。

しかしやってることは、イベントの取得、 FPS カウンタの更新、キー押されたかチェックしてるだけくらいで終了するロジック、画面消して線一本ひいて4つ画像を表示するだけの描画まわり、くらい。

この中では描画が一番秘孔をつきそうかな…と思う。

画像を表示する部分は

   fb.drawImage(images[t+2], x * 16, y * 16);

の一行で、これはさすがに大丈夫だろうと思う。

画面を消す部分は

   fb.fillStyle = 'white';
   fb.fillRect(0, 0, fbW, fbH);

だけで、これも大丈夫だろうと思う。 'white' とかは実装がすごいバカならすごいことになってもおかしくない気がするけど、 WebKit の実装を思い出すに別にバカだった気がしないし、こんなよく使われてるとこがおかしかったらマズい。一応 clearRect に変えてみたりしたけど関係ない。

線一本は

   fb.strokeStyle = 'red';
   fb.moveTo(puyo.offsetX + 16, puyo.offsetY + 16 * 2);
   fb.lineTo(puyo.offsetX + 16 * 7, puyo.offsetY + 16 * 2);
   fb.stroke();

だけ。これもよく使われてる部分だし秘孔つく気もしないな…と思う。でもそういえば closePath ってあったなーと思って、あれって正方形とか書く時に最後の一辺を書くだけぽいから直線にはいらないと思ってたんだけど…と思いつつ入れてみるもなおらない。ひょっとしたら同じ線を書くオペレーションがどんどん積もっていって、 1000 フレーム後には 1000 回同じ線をひいてるとかになってるのかと思ったのだけど。

はてな…と。しかし linux firefox で再現してるのはありがたくて、 android よりはるかに挙動を観測しやすい。 top 動かしてみると、最初は 10% くらいだった firefox の CPU 使用率が徐々に増えていって、 100% になると FPS が減りはじめる。なるほど firefox で大丈夫な時とダメな時があると思ってた理由は、単に待った時間の差か。あとメモリ使用量は増えてない。まあリソース喰い潰してたらもっと大変なことになるよな…と。

となるとやっぱ描画オペレーションが溜まっていってるのかな…と思って、そういえば canvas の getContext('2d') は最初に呼んで取得したコンテキストをずっと使ってるけど、毎フレーム取得しないと良くなかったりするんだっけ…とか思いつついじってみるもなおらない。まああたり前です。

でもとにかくあやしいのは線だよなーと思って、線をかくコードを消してみる。遅くならない。やはりこれかとなる。これをさっさとやれよ…という感じ。遅くなるって現象が起きるのに時間がかかるから、 iteration に時間がかかるんですよね…

で、ちゃんと canvas の API を読みなおそう…と見てみると、 beginPath というのがある。そうか beginPath で前回の描画オペレーションがクリアされるのか俺はアホかーと。 fb.beginPath() を足して解決。

たぶん最近の WebKit には同じ描画が繰り返されたら省略する、みたいな最適化が足されたのかなぁ、というのが今の予想。おせっかいな感じもするけど、機械が生成した canvas のコードとかで重複が結構あるとかはありそうだから、まぁ悪い話ではないのかもしれないなぁ…

というような、なんだかなぁ…としか思えない、くだらないバグだったんだけど、妙に時間を消費した。思ったこととしては、

最近特に自分で使うものなんて、 WebKit 以外どうでもいいべーとか思ってるけど、セカンドオピニオンというか、まぁ他のブラウザで試してみるのもそれなりにした方がいいかな…ということ。 linux chrome で起きなくて android chrome で起きる問題を修正するのに、 firefox が役に立ったんだから…

ゲームぽいことやる時は FPS カウンタって本当に役に立つよね…ということ。

(02:09)