3

HTML5キャンバスで奇妙な現象を見つけました。予想よりも低いフレームレートになりましたが、Firefoxでのみ、1台のコンピューターでのみ(ただし、テストした別のコンピューターでは)ありませんでした。奇妙なことに、キャンバスのサイズを255x250以下に減らすと、Firefoxは他のブラウザと同じように動作します。幅をもう1ピクセル追加すると、FPSは急速に3分の1に低下します。

問題を示すためにjsPerfを作成しました:http://jsperf.com/critical-canvas-size 灰色の長方形が画面に表示されていることを確認してください。表示されていない場合は、結果が変わることがわかったため、テストを失敗させます。誤ってスクロールして離れた場合。)

4つのテストケースはすべて、ほとんどのシステムのほとんどのブラウザで非常によく似ていますが、Firefox 17を搭載したこの1台のPCでは、次のように表示されます。

ここに画像の説明を入力してください

問題のPCは古いRedHatLinuxを実行しており、おそらくハードウェアアクセラレーションをサポートしていないと思います(OS側から)。

それで、これの原因は何でしょうか?この問題を回避するためにコードでできることはありますか?(たとえば、1つの大きなキャンバスではなく、いくつかの小さなキャンバスを使用することを考えていました。)


編集:これは問題を明らかにするスタンドアロンのhtmlファイルとそうでないものです。唯一の違いは、キャンバスの幅である251と250です(スピナーアニメーションをコメントアウトできます。問題を可視化するためだけです。また、FPSタイマーの精度は非常に簡単です。)

250pxバージョンは約60FPSを取得しますが、実際には上限があるようです。変数を増やしてnumIterations、フレーム関数に複数のタイルを描画させることができます。適切なフレームレートを維持しながら、最大numIterations = 100、つまり120000タイル/秒を取得できます。ただし、251pxバージョンでは、numIterations = 1の場合でも、フレームレートが20未満、つまり1000タイル/秒未満になります。

4

2 に答える 2

0

私は実際に同様の行動を見ます。65776ピクセルの壁を越えたときだと思います->期待どおりの65536ではありません。

これがなぜなのかはまだわかりませんが、ブラウザ内の何らかの内部データ構造またはデータ型の問題 (おそらくハッシュを使用しており、その時点でテーブルを拡張する必要がある) である可能性があります。あなたのテストは、私の Chrome ブラウザーでは実際には無効です。同じパフォーマンスの低下は見られません。

私はいくつかのテストケースを書き ましたhttp://jsperf.com/pixel-count-matters/2http://jsperf.com/magic-canvas/2

お役に立てれば!

于 2013-09-26T20:19:09.057 に答える
0

キャンバスへの描画とキャンバスのクリアはコストのかかる方法であるため、これは理にかなっています。より小さなキャンバスを使用clearRectして、すべてのアニメーション ステップを呼び出すと、まったく同じコードを実行するより大きなキャンバスよりも優れたパフォーマンスが得られます。最善の方法は、各フレームの変更内容のみをクリアするように描画方法を最適化することです。これを行うと、パフォーマンスが向上することに気付くでしょう。この記事は、パフォーマンスを向上できるその他の分野に役立ちます。

私も canvas を使って開発していますが、WebKit ベースのブラウザは一般に、ほとんどの場合、Gecko よりも迅速に canvas 操作を処理することがわかりました。

于 2013-01-18T12:27:19.987 に答える