で のデコードを試した pixiv Inc. 2019.9.13 Fukuoka.rs #5 LT

2 自己紹介 ● 主にフロントエンドエンジニア ● ActionScript 3.0 を JavaScript に書き直したり WebGL を駆使したサイトを作ったり PHP のコードをリファクタリングしたり ● ブラウザの限界に迫るのが好き 課題解決部

3 とは ● アセンブリでないバイトコード ● 豊富な実行環境がある ○ モダンブラウザ Chrome / Firefox / Safari / Edge ○ Node.js v8 以降（AWS Lambda, BigQuery など） ○ Wasmer というランタイムを使えば Rust / C / Go / Ruby などで実行できる ● ECMAScript と似た策定プロセスを取っている

4 の策定プロセス ● Phase 1 Feature Proposal ○ 機能追加が承認される ● Phase 2 Proposed Spec Text Available ○ 最初の Spec テキストが作られる ● Phase 3 Implementation Phase ○ Spec テキストが完成し、レビューが完了する ● Phase 4 Standardize the Feature ○ 1つのツールチェイン、2つ以上の実行環境が作られ、承認される

ブラウザにフォーカスして 話していきます 5

6 ブラウザにおける の用途 ● C などで書かれたコード資材（ライブラリ）をブラウザ上で動かす ○ モバイルアプリと Web アプリの一部コードの共通化が出来る ○ Emscripten などを使って WebAssembly or asm.js に変換する ■ なんとか動かすことは出来るが特殊な知識・技術を必要とする ○ C/C++とWebAssemblyを利用したライブラリ開発 https://www.slideshare.net/llamerada-jp/ccwebassembly

7 ブラウザにおける の用途 ● DOM も含めて非 JavaScript で開発する ○ WebAssembly から直接 DOM API を触る機能はまだない ■ Phase 1 Interface Types で議論されている ○ JavaScript の函数は実行できるので DOM API をラップして渡すことは出来る ■ Rust の Yew (wasm-bindgen) や C# (.NET) の Blazor などは自動でラップ ● グルーコードを触れない個人的にあまり好きではない ……

8 ブラウザにおける の用途 ● 重いデコード処理や行列演算などをブラウザで行う ○ JavaScript よりも実行速度が速いためプロダクトの要所で使う ■ 将来的に Phase 2 Threads, Fixed-width SIMD で更に速くできる ○ デコードできないファイル形式を扱うことが出来る ■ 通信コスト削減が出来る 　 WebP 形式の画像は Safari で扱えないが WebAssembly で対応できる？

9 のデコード ● https://github.com/petamoriken/wasm-webp-test ● image クレートを使って WebP のデコードをした（まだ輝度しか取り出せない）

10 結果 ● Chrome ● Firefox ● Safari

11 やってみた感想 ● image クレートの WebP 対応が微妙 ○ 輝度しか対応していない（PR で作業されている） ○ VP8 のチャンクが VP8␣ 始まりでないといけない ■ ImageMagick で生成した WebP が不正扱いになってしまう 要調査 ● WebAssembly のエラー周りが大変 ○ 仕様としては Phase 1 Exception handling で議論されてそう ○ wasm-bindgen を使う場合は console_error_panic_hook を使うと見やすくなる