WebGL: WebAssembly と今後のロードマップについて

昨日、Chrome, Edge と Firefox の開発会社である Google, Microsoft および Mozilla が、WebAssemblyという新しいクロスブラウザテクノロジーについて発表しました。これはとてもエキサイティングなニュースで、なぜならUnityのWebGL向け機能におけるユーザー体験を大きく向上させるものだからです。

WebAssemblyは技術的には新しい、独立した標準として定義されていますが、私たちから見ればこれは要するに asm.js という JavaScript サブセットのバイトコード版と言えます。（asm.jsはUnityのコードをWebGLで動作させるために使用されています）現在のテキストベースの表現と比較すると、バイトコードを使用できることでサイズを圧倒的に小さくすることができます。これはコードをダウンロードする速度を改善するだけでなく、JavaScript上でのコードのコンパイルもより速く、少ないメモリで出来るようになることを意味します。コードのコンパイル速度およびメモリ使用量は、現在UnityのWebGL機能を利用している開発者には、いくつかあるよく知られた問題の一つです。
私たちは、ブラウザがサポートをし次第、UnityのWebGL出力をWebAssemblyバイトコードに切り替える予定です。この機能をネイティブでサポートしないブラウザについては、バイトコードはJavaScriptを使ってブラウザ上で大変効率よくテキストベースのasm.jsに変換出来るため、そのような対応にする予定です。 – その場合でも、ダウンロードサイズが小さくなることで、最終的にコンテンツをロードするまでの時間はほとんどのケースで改善するでしょう。

私たちがWebAssemblyフォーマットを実験してみたところ、AngryBotsを使ったデモではasm.jsを使ったケースでは、生成されたコードは19.0MB ( gzipに圧縮後は4.1MB ) であったのに対し、WebAssembly バイトコードでは6.3MB ( gzip圧縮後は3.0MB ) まで小さくなりました。これはどう言うことかというと、ブラウザが処理しなければならないデータ量は1/3になり、さらにダウンロードサイズはおよそ3/4にすることが出来たというわけです。当然、削減効率自体はプロジェクトによって左右しますが、UnityのWebGL機能をつかうプロジェクトでは、全体的に同傾向の改善が見られることを期待しています。
WebAssemblyについてさらに知りたい場合は、こちらのFAQをご覧下さい。

このアナウンスメントに続いて、現在のWebGLに対する開発の状況や、次の一年間のうちに私たちが期待しているエコシステムの変化についても共有したいと思います。
たとえば、私たちは現在、さらなるビルドサイズの改善、SIMD.js対応、 Shared Array Buffers 対応 ( JavaScriptにマルチスレッド機能を提供します ) そしてWebGL 2.0 などに取り組んでいます。もっと詳しくお知りになりたい方は、ぜひ WebGL Roadmap フォーラム もチェックしてみてください。そちらにはより多くの情報を掲載しています。

もし、来週欧州で行われる Unite アムステルダム にお越しの方は水曜日の私のWebGLに関するセッションにご参加頂くか、ハンズオンラボに来て質問をいただければと思います。