読者です 読者をやめる 読者になる 読者になる

Mozilla Flux

Mozilla関係の情報に特化したブログです。

Firefox 51から53までWebゲームプラットフォームとしての機能を段階的に強化(追記あり)

MozillaはこれまでもFirefoxをWebゲームの強力なプラットフォームにすべく改良を重ねてきたが、Firefox 51以降の3バージョンの間にそのステージを1段階引き上げる。3Dの表現力だけならPlayStation 3/Xbox 360世代に匹敵する水準となり、ゲームのロードから開始までの時間が短縮され、動作の安定性も向上する。具体的にどのような変化が起きるのか紹介しよう。

Firefox 51

最近リリースされたFirefox 51では、WebGL 2が初期設定で有効化された。これを踏まえたプレイアブルなデモが、PlayCanvasの"After the Flood"である。大洪水後の荒廃した未来の町並みが美しいグラフィックスで描写されており、2012年3月に公開されたBrowserQuestと比べると、表現力の進歩を実感できるだろう。

www.youtube.com

WebGL 2はOpenGL ES 3.0がベースになっており、WebGL 1(OpenGL ES 2.0ベース)とは緩やかな後方互換性を保っている。WebGL 2の処理パイプラインの構造はWebGL 1のものをほとんど踏襲しているが、新機能の追加によって3D APIの表現力が増強されている。たとえば複数のテクスチャに対し同時に書き込みができるようになり(Multiple render targets)、複数のインスタンスを1回の描画命令で描画することが可能になった(Instanced geometry drawing)。また、3Dテクスチャや2Dテクスチャ配列がサポートされ、頂点シェーダで計算した結果を頂点バッファオブジェクトに書き込むこともできる(Transform feedback)。

Mozillaは今後、WebGL 2 APIのパフォーマンスを向上させるほか、一部の制約を緩和するなどAPI自体も洗練させていくとしている。

参考:WebGL 2 lands in Firefox ★ Mozilla Hacks / WebGL 2.0の概要 - Qiita

Firefox 52

Firefox 52ではWebAssemblyが初期設定で有効化される予定だ。JavaScriptのサブセットにすぎないasm.jsとは異なり、WebAssemblyはバイナリフォーマットを採用しているのでコンパクトだ。2016年3月時点で、そのサイズは非圧縮のasm.jsよりも42%小さいとされていた。現在はさらに差が開いている可能性がある。

パフォーマンスの面でも、WebAssemblyはasm.jsよりも良好なスループットを達成している。また、コンパイル時間の短縮も図られており、Unityのテストで3420ミリ秒から1492ミリ秒になったという話もある(Bug 1317033)。

このWebAssemblyに関連して、Large-Allocation Headerという機能が32bit版向けにFirefox 52で有効化されるかもしれない(Bug 1331083)。この機能はマルチプロセス化(e10s)を前提にするもので、ドキュメントにこのヘッダが付いていると、読み込み予定のページに独立したプロセスが割り当てられる。そのプロセスでは大量の連続的なメモリを確保できるので、WebAssemblyベースのゲームを読み込む際に有効であるというわけだ。

以上とは別に、Firefox 52ではSharedArrayBufferおよびAtomics APIが初期設定で有効化される(Bug 1312446)。SharedArrayBufferは、スレッド間で共同利用できるバッファを作ることができるというもので、そのバッファの操作やスレッドの制御を行うのがAtomics APIだ。

SharedArrayBufferが導入された背景については、A Taste of JavaScript’s New Parallel Primitives ★ Mozilla Hacksに説明がある。その和訳であるJavaScript の並列処理機能を味見してみる | Mozilla Developer Street (modest)から引用しておく。

これらに代表される JS (注:JavaScript)の適用範囲の拡大は、パフォーマンスの驚異的な改善によって可能となりました。それは JS エンジンに実装された Just-in-Time(JIT) コンパイラや、より高速な CPU によってもたらされました。

しかし、JIT による実行速度向上のスピードは低下しつつあります。また CPU 速度の改善はほとんど頭打ちになっています。CPU の高速化に代わる手法として利用されているのは、複数の CPU(実際は CPU のコア)の利用です。これは携帯電話からデスクトップにいたるまで広く利用され、ローエンドの環境を除けば、最低でも 2 つ以上の CPU が利用できるようになっています。このような状況でプログラマがプログラムの性能を向上させたいなら、複数のコアの並列利用を選択するでしょう。これは Java、Swift、C#、C++ のようなマルチスレッドプログラミングが可能な言語で書かれたネイティブアプリの話ではありません。Web Worker と、その遅いメッセージパッシング機構、そしてデータコピーの回避手段がほとんどないという、複数の CPU を利用するには極めて制限された機能しか持たない JavaScript での話です。

つまりは JS には問題があるのです:Web 上の JS アプリケーションが、ネイティブに代わる有力な選択肢であり続けるためには、JS を複数 CPU の上で動作させられるような機能を JS に持たせなければなりません。

要するにSharedArrayBufferは、PC側の複数CPUコアを利用して、並列に計算させることでJavaScriptの処理速度を向上させるための仕組みだ。重いゲームを動かす際に力を発揮することは、いうまでもない。

参考:SharedArrayBufferとAtomics APIについて - JS.next

Firefox 53

Firefox 53では、別記事に書いたとおり、適格性のあるWindowsユーザーに対し軽量インストーラ(スタブインストーラ)が初期設定で64bit版をインストールするようになる(Bug 797208)。64bit版はOOM(out of memory:低メモリ)クラッシュが減って安定性が向上するだけでなく、パフォーマンスも向上することがベンチマーク結果から明らかになっている。

Windows版でQuantum Compositor(旧名GPUプロセス)が初期設定で有効化される点も見逃せない(Bug 1330554)。Geckoのcompositorに独立したプロセスを割り当てるこの機能は、GPUドライバが原因のクラッシュを45%も減少させる。64bit版である場合やDirect3D 11を使用する場合には、クラッシュ率を全般的に引き下げる効果も認められている。

(17/02/12追記)
Firefox 51以降の動きを紹介する主旨なので本文では触れていないが、2016年中にWeb Audio APIの仕様変更に追随するなど、オーディオ面でも性能は向上している。

(17/03/09追記)
Firefox 52の初期設定でWebAssemblyが有効化された(Bug 1342060)。他方、Large-Allocationヘッダは、Firefox 53(32bit版のみ)で有効化される見通しである。

(17/03/13追記)
WebAssembly + WebGL 2.0を駆使したZen Gardenデモが公開されている。高精細な3D画面が次々に展開されていく美麗なデモではあるが、ファイルサイズが約100MBあり、動作にかなりのマシンパワーとメモリを必要とする。Webの最先端を示すものといえよう。

www.youtube.com

その一方で、軽量インストーラが初期設定で64bit版をインストールするようになる時期は、Firefox 55へと後退した。64bit版でFlashの非同期レンダリングのサポートが遅れていることが原因である。ただ、Firefox 53のWindows向けインストーラでは、オプション画面でユーザーが32bit版と64bit版のいずれをインストールするか選択できる