Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
本記事は、マイクロソフト本社の IE チームのブログ から記事を抜粋し、翻訳したものです。
【元記事】Using PC Hardware more efficiently in HTML5 New Web Performance APIs Part 1 (2011/7/6 8:43 AM)
HTML5 アプリケーションの持つ快適性を実現するには、ブラウザーにも優れたパフォーマンスが求められます。Web 開発者は、HTML5 を通じて最新のコンピューター ハードウェアを効果的に活用し、電力消費が効率化された高性能の Web アプリケーションを構築して、広範なニーズに応える優れたカスタマー エクスペリエンスを提供するための API を必要としています。IE10 Platform Preview 2 では、W3C Web Performance Working Group が定義する、requestAnimationFrame、Page Visibility、setImmediate の 3 つの新しい API に対するサポートが導入されました。これらの API は基盤となるハードウェアを最大限に活用し、バッテリの電力をより効率的に使用するために必要な機能を提供します。
私たちは Google、Mozilla、その他の W3C Web Performance Working Group メンバーおよびコミュニティの参加者と協力して、この 3 か月間でこれらの新しい API を設計しました。新しいアイデアを基に、開発者が安心して使用できる相互運用可能な HTML5 対応ブラウザーの標準をごく短期間で作成できることを示した良い例です。
この記事では、requestAnimationFrame API を使用して、パフォーマンスの向上と電力消費の効率化を実現する方法について説明します。
requestAnimationFrame API: setTimeout に似ているが、より無駄のない処理を実現
この API により、Web 開発者が電力消費を抑え、アニメーションの途切れを解消できるようなアニメーションのスケジューリングが可能になりました。最近のアニメーションは、Web サイトがバックグラウンド タブで開かれていたり最小化されていたりしてユーザーに見えない状況でも再生が続行され、貴重なバッテリの電力を浪費する傾向にあります。また、通常、アニメーションがディスプレイのリフレッシュ レートと同期していないため、再生が途切れがちになります。requestAnimationFrame API の登場以前は、Web プラットフォームにおいて、Web 開発者がアニメーションのグラフィックス タイマーをスケジューリングするための効率的な API は提供されていませんでした。
1 つ例を見てみましょう。多くのアニメーションでは、精度が 16.7 ミリ秒未満の JavaScript タイマーでアニメーションを描画していますが、モニターは 16.7 ミリ秒周期 (周波数 60Hz) でしか更新できません。最初のグラフは、16.7 ミリ秒のディスプレイ モニターのリフレッシュ レートを表しています。2 番目のグラフは、標準的な、10 ミリ秒に設定された setTimout または setInterval のタイマーを表しています。この場合、常に 3 回目の描画がユーザーに表示されないことになります。ディスプレイが更新される前に次の描画が開始されるためです。このように描画が多すぎる結果として 3 回に 1 回の割合でフレームが失われるので、アニメーションの再生が途切れ途切れになります。とはいえ、タイマー精度を下げると、バッテリ持続時間に最大 25% の悪影響が及ぶ場合があります。
上の図は、各矢印が 、 16.7 ミリ秒周期のモニターの更新を表します。下の図は、10 ミリ秒周期のページの再描画を表します。3 回に 1 回の割合で再描画がモニターに表示されず、無駄になります。
結果として、アニメーションは途切れ途切れになり、バッテリは浪費されます。
requestAnimationFrame API は、現在開発者に使用されている setTimeout API および setInterval API に似ていますが、大きな違いは、この API は、ブラウザーで画面を更新する必要があるときにのみ、フレームを更新するようアプリケーションに通知する点です。これによって、Web アプリケーションとブラウザーの描画が完全に同期して、必要な量のリソースだけが使用されます。
以下の画像に示した requestAnimationFrame のデモを見ると、アニメーションは同じように見えても、requestAnimationFrame を使用して描画された時計は、電力消費、バックグラウンド処理への影響、CPU 効率のすべての面で、setTimeout を使用している時計よりも効率的であることがわかります。
requestAnimationFrame のアニメーション (右) は、電力消費、バックグラウンド処理への影響、
CPU 効率において、setTimeout のアニメーション (左) よりも効率的です。
現在のアニメーションでこの新しい API を使用するためのアップグレード手順は単純です。現在のコードで setTimeout(draw, PERIOD); を使用している場合は、それを requestAnimationFrame に置き換えます。requestAnimationFrame API は新しい 3 つの API の中で最も普及が進んでおり、既に Firefox 4、Chrome 13、および Internet Explorer 10 をはじめとするブラウザーで、相互運用性のある、ベンダー プレフィックス付きの実装が可能になっています。
requestAnimationFrame は setTimout と同様に、単一のコールバックのみをスケジュールする点に注意してください。後続のアニメーション フレームを設定する場合は、コールバック内から再び requestAnimationFrame を呼び出す必要があります。Internet Explorer は今回の Platform Preview で、この API を他のブラウザーと同様にベンダー プレフィックス付きで実装しています。将来も有効なクロスブラウザー対応のマークアップを記述する方法を、次の例に示します。
// 将来も有効: 機能が完全に標準化された場合
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);
// Internet Explorer の実装
else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw);
// Firefox の実装
else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw);
// Chrome の実装
else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw);
// まだこの機能をサポートしていない他のブラウザー
else setTimeout(draw, PERIOD);
これらの API の設計にご協力くださった W3C Web Performance Working Group の皆様に、感謝の意を表します。また、相互運用性の確立に向け、これらの API の実装にいち早く着手してくださった他のブラウザー ベンダーの皆様にも感謝いたします。これらの API によって、Web 開発者はより高速で省電力な Web を作成できるようになるでしょう。
—Jatinder Mann、Internet Explorer プログラム マネージャー