これからMozillaがどんなゲームプラットフォームを作っていくか？[翻訳]

(7/8am 公開)
(7/8pm 書式設定追加、誤記変更)
(7/13pm 指摘事項修正、文中のリンク追加)
お世話になってるMozillaのコミュニティから、ゲームプラットフォームのロードマップ(将来展開)について訳してみないか？と募集があった(ブログ記事(Mozilla Games Technology Roadmap) · Issue #63 · mozilla-japan/translation · GitHub)ので、訳してみました。
あいかわらずアルゼンチン時間ですが、某バグハンターの娘さんに送ります。

原文
Mozilla Games Technology Roadmap - Future Releases

翻訳
ゲームとゲーム技術向けプラットフォームとしてのWebの更なる進歩やアピールのため、Mozillaはゲームに特化したロードマップ(Platform/Games - MozillaWiki)を発行しました。要するに、これは高パフォーマンスで、プラグインなしのWeb上のゲームに関するものです。最近数年で我々はめざましい進歩をとげました。この流れを続けるため、Mozillaはゲーム開発者やツールメーカーと協働し、コミュニティへより大きな力を与える追加改良を割り出しました。次のロードマップは、我々が受けたフィードバックと、そのフィードバックに応えて現在追求している解決策の両方をざっと示しています。このロードマップは変化しがちであるかもしれません。

WebAssembly が明らかになるにつれ、各プラウザはWebパフォーマンスがネィティブレベルになるよう、共通の対策を取ってきています。このロードマップは、ゲーム開発者が最善のエクスペリエンスを提供するためにWebプラットフォームに追加された機能について、より広がった視点をざっと示します。ゲームはしばしば、その要求する性質から、技術を進める大きなきっかけになります。Webへの利益を最大化するために、解決策ができるだけ広い範囲のアプリケーションに利益となることを保証するよう、注意が払われています。

この文書には2つのレベルがあり、最初はロードマップの節で、現在開発中で来年に取り組める、合理的なレベルで自信を持っているものを含んでいます。2つ目は検討中の節で、研究活動中のトピックを含んでいます。

ロードマップ

開発者に、ハードウェアの並行性をより良く利用できるようにする

  1. 開発者はWeb上でマルチスレッドのゲームが効率よく動作するようになるように格闘しています:
    1. 共有配列バッファの標準化、実装、出荷 [1,2].
    2. Emscriptenへのpthreadサポート追加 [1,2].
    3. パフォーマンスに敏感な次のWeb APIをWebワーカに晒す: WebGL, WebSockets, IndexedDB, WebAudio, WebRTC, WebVR
    4. ワーカ間でコンパイル済みコード(asm.js や WebAssembly) を共有する [1].
  2. 開発者は SIMD ハードウェアがコード最適化してくれるのを望んでいます:
    1. SIMD.jsの標準化、実装、出荷 [1,2].
    2. SIMD を WebAssembly 内に含める [1].
    3. EmscriptenへのSIMD サポート追加 [1].

大規模なコンパイル済みコードベースのコールドロード時間を改善する

  1. 開発者は、数百万行のコンパイル済みコードベースのダウンロード、コンパイル、スタートアップ時間が削減されることを望んでいます。
    1. WebAssembly は目立ったダウンロードサイズ圧縮を提供するでしょう (polyfill経由でのネイティブサポートがなされる以前であっても) [1].
    2. ネイティブにデコードされた WebAssembly は JavaScript/asm.js のパーズよりも、はるかに高速でしょう [1].
    3. WebAssembly/asm.js に高速コンパイラを追加して、バックグラウンドのスレッド内で完全な最適化コンパイルを進めて、アプリが素早く起動できるようにする [1].
    4. メインスレッド以外で、パーズ/コンパイルをストリーミング化 [1].
  2. 開発者はHTTP コンテンツエンコードに依存するのを避けたがっています: 汎用的な圧縮にはgzipを使う
    1. Emscripten に対して、asm.js / WebAssembly 内で、ダウンロード中の展開(gzipよりもっと積極的なアルゴリズムを許可する)を実行するサポートを追加


ブラウザストレージの能力を改良する

  1. 永続ストレージに関する権限のプロンプト(Storage Standard)を避けようとしている開発者は、現在ブラウザに実装されている一時ストレージの制限につき当たります。
    1. Frecency(Frecency - Wikipedia) のような要因を考慮に入れるため、一時クオータ制限を改良する
    2. クオータ使用と許可に関するもっと詳細な商法提供 [1].
    3. 強制退去可能な(evictable)ストレージの精度単位を細かくすることの提案、標準化、実装 [1].
    4. クロスオリジンのストレージ使用の許可 [1].
  2. 永続ストレージの保証を必要とする開発者は、現在ブラウザに実装されている一時ストレージの制限につき当たります。
    1. 永続化ストレージの標準化して、他のブラウザが実装できるようにする [1].
    2. 永続化パーミッションのプロンプトに関する、UI 摩擦の削減 [1].
    3. ブラウザユーザ向けに、ストレージ管理/強制退去(eviction)の改良

ブラウザのグラフィック能力を改良する

  1. WebGL2を出荷[1].
  2. WebRTC経由でのWebGLキャンバスのストリーミングの標準化や実装 [1,2].
  3. 統合+ディスクリートつきのシステム向けディスクリートハードウェア (例 nVidia Optimus)でWebGLを実行する

開発者が32-bitブラウザのメモリ不足(Out-of-Memory)条件をうまく避けられるようにする

  1. 64-bit Windowsで64-bit Firefoxの出荷
  2. pthreadsとFileReaderSync(FileReaderSync - Web APIs | MDN)が同期ファイルI/Oをワーカーに供給するよう、てこ入れすることで、Emscriptenがアセットストレージ用のメモリ内仮想ファイルシステムを避けます

プラットフォームをまたいだパフォーマンスへの投資を続ける

  1. WebAudio パフォーマンスの、重要な最適化 [1].
  2. WebGL シェーダーのコンパイル時間の削減 [1,2].
  3. ブラウザのレンダリングパイプライン内で、遅延やバラツキの削減 [1,2,3,4].
  4. JS, DOM, WebGL, WebRTC, codec, layout, rendering, compositing, animation, などへの継続的投資

Emscriptenへの投資を続ける

  1. すでに記載の通り、pthreads, SIMD, WebAssemblyのサポート追加
  2. コンパイルスピードのいっそうの改良

Firefox 開発ツールがより良いゲーム開発者サポートするよう投資を続ける

  1. Web ワーカのサポート改良 [1].
  2. 開発者が asm.js/WebAssembly のさまざまなエラー条件にブレークポイントを貼れるようにする [1].

製作中

開発者は、負荷を分配するのにいくつのWebワーカを作成したら良いかを決めるのに困っています。しばしばベンチマークメソッドが信頼できることがわかっています。
開発者はFirefoxでのWebワーカがオリジン毎に20である制限につき当っており、もっと高い制限を要求しています。
プロセス起動の初期に配分された大きな隣接ヒープで、ゲーム用の新鮮なアドレススペースを保証するマルチプロセスブラウザアーキテクチャをてこ入れします。
メモリ不足(Out-of-Memory)エラーの報告メカニズムを研究して、安全な/サニタイズ済みの選別情報をWebアプリ開発者に戻す。
IME 能力の改良のための新標準の共同研究 [1,2].
ハードウェアカーソルAPIの追加 [1].
ゲームパッドAPIの改良 [1].
ポインターロックAPIへポインターをクリップする拡張を追加 [1].
メモリ使用/リーク のデバッグ用Emscripten ツールの追加
大規模なコンパイルコードに適した、よりスケーラブルなソースマップ形式の標準化(WebAssembly の一部や、より一般的に)