[この記事は”Where is WebAssembly now and what’s next?“の翻訳です]この記事は WebAssembly と何が速くしたのかのシリーズの6部です。もしまだ前の記事を読んでいない場合、最初から読むことをお勧めします。

2月28日、4つのメジャーなブラウザが WebAssembly の必要最低限の機能のみを持つ製品 (MVP) が完了したという コンセンサスを発表しました。

これにより、ブラウザが出荷できる安定したコアが提供されます。このコアには、コミュニティグループが計画している機能のすべてが含まれているわけではありませんが、WebAssembly を高速かつ使いやすくするために十分な機能を備えています。

これにより、開発者は WebAssembly コードの提供を開始できます。以前のバージョンのブラウザでは、開発者は asm.js バージョンのコードを提供できます。asm.js は JavaScript のサブセットであるため、どの JS エンジンでも実行できます。Emscripten を使用すると、同じアプリケーションを WebAssembly と asm.js の両方にコンパイルできます。

初回リリースであっても WebAssmbly は高速に動くでしょう。しかし修正と新規機能を導入により将来的にさらに高速になるでしょう。

ブラウザー上の WebAssembly のパフォーマンス向上

ブラウザーエンジンが WebAssembly のサポートを向上させるとスピードが向上します。ブラウザベンダーはこれらの問題を個々に取り組んでいます。

JS と WebAssembly 間の関数呼び出しの高速化

現在 JS からの WebAssembly 関数呼び出しは求められるスピードに達していません。その理由は「トランポリン」と呼ばれることが原因です。JIT は WebAssembly をどのように扱えばよいのか知らないため、WebAssemblyを何かにルーティングする必要があります。これは最適化された WebAssembly コードを実行するためのセットアップ時のエンジン自体のコードが遅い箇所です。

これは JIT が直接処理する方法を知っていた場合よりも、最大100倍遅くなることがあります。

単一の大きなタスクを WebAssembly モジュールに渡している場合は、このオーバーヘッドに気付かないでしょう。しかし WebAssembly と JS の間で多くのやりとりがある場合 (小規模な作業と同じように)、このオーバーヘッドが目立ちます。

より速いロード時間

JIT はより速いロード時間とより速い実行時間の間のトレードオフを管理する必要があります。コンパイルや最適化に時間を費やすと実行速度が向上しますが、起動が遅くなります。

先進的なコンパイル (コードが実行されるとジャンクが発生しないようにする) と、コードのほとんどの部分がそれに見合った最適化を行うために十分な時間実行されないという基本的な事実とのバランスを取るために、多くの進行中の作業があります。

WebAssembly はどの型が使用されるかを特定する必要が無いため、エンジンは実行時に型をモニターする必要がありません。これは実行時の平行コンパイルといった例のような様々なオプションをもたらします。

さらに JavaScript API への最近の追加では WebAssembly のストリーミング・コンパイルが可能です。これは WebAssembly のデータをダウンロード中にエンジンがコンパイルを開始できることを意味します。

Firefox では二つのコンパイラーを使用するシステムになっています。一つ目のコンパイラは事前に実行し、コードを最適化を行います。コードの実行中は別のコンパイラがバックグラウンドで完全な最適化を行います。完全に最適化されたバージョンのコードへ準備が整うと切り替わります。

MVP リリース以降の機能導入

WebAssembly の目標の 1 つは、すべての機能を設計するのではなく、小さなチャンクで指定し、途中でテストを行うことです。

期待されている機能はたくさんあるが、100% の考え方はまだ存在しないことを意味しています。これらはブラウザベンダが参加している使用策定プロセスを経る必要があります。

これらの機能は将来の機能と呼ばれています。少し紹介します。

DOM を直接扱う

現在 DOM を扱う手段はありません。これは WebAssembly から element.innerHTML のようにノードを更新できないこと意味します。

代わりに、値を設定するために JS を経由する必要があります。これは値を JavaScript 呼び出し側に渡すことを意味します。一方、WebAssembly 内から JavaScript 関数を呼び出すことは、JavaScript と WebAssembly の両方の関数を WebAssembly モジュールをインポートして使用できることを意味します。

いずれにしても、JavaScript を使用することは直接アクセスよりも遅くなる可能性があります。WebAssembly の一部のアプリケーションはこれが解決されるまでが続くかもしれません。

共有メモリーの同時実行性

コードを高速化する方法の 1 つは、コードの異なる部分を同時に並列で実行できるようにすることです。しかし、スレッド間の通信のオーバーヘッドは、タスクを分けずに実行するよりも多くの時間を要する可能性があるため、時には逆効果になる場合があります。

しかしスレッド間のシェアードメモリを使用すればこのオーバーヘッドを削減できます。これを実施するため WebAssembly は JavaScript の新しい SharedArrayBuffer を使用すべきです。これがブラウザに組み込まれると、ワーキンググループは WebAssembly の動作方法を指定することができます。

SIMD

WebAssembly　に関する他の投稿を読んだり、話を聞いたりすると、SIMD　のサポートについて聞かれることがあります。頭字語は、単一命令、複数のデータを表します。物事を並行して運用する別の方法です。

SIMD を使用すると、異なる数のベクトルのような大きなデータ構造を取り、同じ命令を異なるパーツに同時に適用することができます。このようにして、ゲームや VR に必要な複雑な計算を大幅に高速化できます。

これらは平均的な Web 開発者にとってさほど重要ではありません。しかしゲーム開発者のようなマルチメディアを扱う開発者にとって非常に重要です。

例外ハンドリング

C++ のような言語の多くのコードは例外を使用しています。しかし例外は WebAssembly の一部としてまだ定義されていません。

あなたのコードを Emscripten でコンパイルした場合、いくつかのコンパイラ最適化レベルの例外処理をエミュレートします。これは非常に遅いため、DISABLE_EXCEPTION_CATCHING フラグを OFF にできます。

WebAssembly で例外がネイティブに処理できるようになると、このエミュレーションは必要ありません。

開発者にとってより簡単にするその他の改善

いくつかの将来の機能はパフォーマンスは改善しませんが、WebAssembly を使用するにあたり開発者がより簡単に使用できるようになるでしょう。

• ファーストクラスのソースレベル開発ツール. 現在ブラウザ上で WebAssembly をデバッグすることは、生のアセンブリーをデバッグするようなものです。しかし、ソースコードがアセンブリにどのように変換されるかに関して精通している開発者はほとんどいません。開発者がソースコードをデバッグできるように、ツールサポートを改善する方法を検討しています。
• ガベージコレクション. 事前に型を定義できる場合は、コードを WebAssembly に変換する必要があります。したがって TypeScript のようなコードを使用するコードは、WebAssembly にコンパイル可能である必要があります。WebAssembly は JS エンジンに組み込まれているような既存のガベージコレクタとやりとりができないというのが現状です。この将来の機能のアイデアは、WebAssembly に低レベルの GC プリミティブタイプとオペレーションのセットを使用して、組み込み GC へのファーストクラスのアクセスを与えることです。
• ES6 モジュールの統合. ブラウザは現在、script タグを使用して JavaScript モジュールを読み込むためのサポートを追加しています。 この機能を追加すると、url が WebAssembly モジュールを指している場合でも<script src=url type="module">のようなタグが機能します。

結論

WebAssembly は今日でも高速で、そしてブラウザの新しい機能や実装の改良により、さらに高速化するはずです。

Lin Clark に関して

• code-cartoons.com
• @linclark

Lin Clark によるその他の記事はこちら…

[この記事は”A cartoon into to WebAssembly“の翻訳です]

WebAssembly は高速です。あなたはおそらくこのことは聞いたことがあるでしょう。しかし何が WebAssembly を高速に動作することをできるようにしているのでしょうか？

このシリーズでは、なぜ WebAssembly が高速に動作するのかの説明を行いたいと思います。

WebAssembly とは何ですか？

WebAssembly は JavaScript 以外のプログラミング言語で書かれたコードをブラウザ上で実行する方法です。人々が WebAssembly が高速と言っているときは、JavaScript と比較しています。

パフォーマンスの歴史を少し

JavaScript は1995年に作成されました。しかし高速に動くように設計されてはおらず、最初の10年は速くありませんでした。

その後ブラウザはより競争的になりました。

これらの JIT の導入により、JavaScript のパフォーマンスに変革がもたらされました。 JavaScript の実行速度は 10 倍になりました。

もしかすると我々は今、WebAssembly によって新たな変曲点にいるのかもしれません。

では、WebAssembly を高速化する要素を理解するために詳細を掘り下げてみましょう。

背景:

• ジャスト・イン・タイム (JIT) コンパイラの短期集中コース
• WebAssembly の短期集中コース

過去の WebAssembly:

• WebAssembly モジュールの作成と操作
• WebAssembly を速くするには？

未来の WebAssembly:

• WebAssembly は今どこにあり、次に何があるのか

[この記事は、Control mechanisms in JavaScript games の翻訳です。]

ラップトップやデスクトップをはじめ、スマートフォンやタブレット、TV や冷蔵庫でさえも、共通してブラウザを持つようになりました。ということは、それらの端末上で HTML5 ゲームをプレイできるようになったという風にも思えますが、実際にプレイするためには、ゲーム画面を描画するのと同時に、何らかの方法でゲームを操作できなければなりません。キーボードやマウスはもちろん、タッチ操作、ゲームパッド、TV リモコン、さらにはバナナに至るまで、それぞれのプラットフォームごとに適した選択肢はたくさん存在します（MDN では、control mechanisms に関する一連の記事でそれらのインターフェースを取り上げています）。

今回は、実際のプロジェクトにおける例として、Phaser を用いて作成された Captain Rogers: Battle at Andromeda のデモを使ってぞれぞれの操作方法の実装方法について紹介します。プラットフォームの違いによってゲームの操作性がどう変わっていくかをご確認ください。また、異なるプラットフォームに対応する際に別々にビルドする必要がないということもお見せします。ウェブのマルチプラットフォームという特性によって、コーディングに多くの労力を費やすことなく複数のデバイスに対応できることがお分かりいただけると思います。

また、GitHub には、小さいですが純粋な JavaScript によるデモがオープンソースとして公開されています。操作方法がどのように実装されているかを実際に確認できるので、ご自身のゲーム開発プロジェクトでもお使いいただけます。以下に、主な項目をハイライトでご紹介しますので、このままお読みいただいても良いですし、今すぐコーディングを開始しても良いでしょう。

モバイル タッチ

HTML5 ゲームではモバイルファースト開発が人気ですので、まずはモバイル タッチへの対応から見ていきましょう。

document.addEventListener("touchstart", touchHandler);
document.addEventListener("touchmove", touchHandler);
function touchHandler(e) {
    if(e.touches) {
        playerX = e.touches[0].pageX - canvas.offsetLeft - playerWidth / 2;
        playerY = e.touches[0].pageY - canvas.offsetTop - playerHeight / 2;
    }
}

たった数行の JavaScript コードですが、これがゲーム内でタッチ操作を実現するために必要な最低限のコードです。これだけでモバイル端末上で機能します。最初の 2 行は、タッチ操作に対するイベントリスナーの設定です。それぞれ、画面をタッチしたとき、および、指で画面をなぞったときに対応します。関数内では、タッチ操作が行われたことを確認し、プレイヤーの座標を設定しています。これにより、ゲームの Canvas 上でプレイヤーの機体が正しい位置に描画されます。

上記はベースとなるコードですので、ここからマルチタッチやジェスチャーなど様々な発展形を実装することができます（むしろ、実装した方がいいでしょう）。ゲームの種類や、何をどのように操作するかということを考慮して、実装する操作方法を決めましょう。また、移動用の矢印や発射ボタンなど、特定のアクションを起こすためのボタンを画面上に設置することもできます。詳しくは、Mobile touch controls をご覧ください。

デスクトップ マウスとキーボード

移動用の矢印について触れましたが、モバイル端末向けに画面上に矢印を表示するのはもちろん、デスクトップ向けにそれらを実装することも可能です。ゲーム内のキャラクターを動かす方法としては、カーソルキーや WASD キーがよく使われます。例えば、以下のコードではカーソルキーを使用しています。

document.addEventListener("keydown", keyDownHandler);
function keyDownHandler(e) {
    if(e.keyCode == 39) {
        rightPressed = true;
    }
    else if(e.keyCode == 37) {
        leftPressed = true;
    }
    if(e.keyCode == 40) {
        downPressed = true;
    }
    else if(e.keyCode == 38) {
        upPressed = true;
    }
}

押されたキーを定常的に検出しその情報を保存するということですので、これは描画ループとして以下のように処理することが可能です。

function draw() {
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    if(rightPressed) {
        playerX += 5;
    }
    else if(leftPressed) {
        playerX -= 5;
    }
    if(downPressed) {
        playerY += 5;
    }
    else if(upPressed) {
        playerY -= 5;
    }
    ctx.drawImage(img, playerX, playerY);
    requestAnimationFrame(draw);
}

プレイヤーの位置 x および y を表す変数が調整され、機体画像が新たな位置に表示されます。

一方、デスクトップにおけるマウスは、コーディングにおいてモバイルのタッチと非常に似ています。タッチやクリックが起こった場所に関する情報を取得し、プレイヤーの位置を更新するだけです。

document.addEventListener("mousemove", mouseMoveHandler);
function mouseMoveHandler(e) {
    playerX = e.pageX - canvas.offsetLeft - playerWidth / 2;
    playerY = e.pageY - canvas.offsetTop - playerHeight / 2;
}

マウスポインターの位置が変化するたびに mousemove イベントが検出されるので、プレイヤーの位置がマウスポインターの中央の位置に来るように調整します。こうして、デスクトップのキーボードとマウスの両方で操作可能なゲームを実現することができます。さらに詳しく知りたい方は、Desktop mouse and keyboard controls をご覧ください。

ゲームパッド

個人的に大好きな操作方法です。プレゼンテーションを行う際は、HTML5 ベースの自分のスライドを Gamepad APIを使って操作しているくらいです。ゲームパッドについては、すでに数回お話したこともありますし、ゲームもいくつか実装したこともあります。詳しくは、Gamepad API Content Kit に全て記載しています。 とにかく、コンピューター上でコンソール気分を体験できることは本当に素晴らしいと思いますし、それがウェブ技術によって実現されているということも素晴らしいと思います！ゲームパッドを使用すれば、Captain Rogers のプレイ体験がさらに向上しますし、単純に良い気分になります。

Gamepad API への対応はタッチやキーボードよりもやや複雑になりますが、それでも非常に簡単です。

window.addEventListener("gamepadconnected", gamepadHandler);
function gamepadHandler(e) {
    controller = e.gamepad;
}
function gamepadUpdateHandler() {
    buttonsPressed = [];
    if(controller.buttons) {
        for(var b=0; b<controller.buttons.length; b++) {
            if(controller.buttons[i].pressed) {
                buttonsPressed.push(b);
            }
        }
    }
}
function gamepadButtonPressedHandler(button) {
    var press = false;
    for(var i=0; i<buttonsPressed.length; i++) {
        if(buttonsPressed[i] == button) {
            press = true;
        }
    }
    return press;
}

ゲームパッドが接続されるとイベントが発生し、ゲームパッドに関するデータの参照が変数に保存されます。以降は、その変数を使用してゲームパッドに関するデータにアクセスします。更新が起こると、押されたボタンの配列が新たに生成されるため、常に最新の状態が保持されます。また、あるボタンが押されたかどうかを判定するために配列をループ処理する関数もあります。これらはキーボードチェックと同様に、描画ループの中で使用できます。

function draw() {
    // ...
    gamepadUpdateHandler();
    if(gamepadButtonPressedHandler(0)) {
        playerY -= 5;
    }
    else if(gamepadButtonPressedHandler(1)) {
        playerY += 5;
    }
    if(gamepadButtonPressedHandler(2)) {
        playerX -= 5;
    }
    else if(gamepadButtonPressedHandler(3)) {
        playerX += 5;
    }
    if(gamepadButtonPressedHandler(11)) {
        alert('BOOM!');
    }
    // ...
}

こうすることで、プレイヤーの機体を DPad ボタン（十字キー）で操作したり、A ボタンで爆弾を爆発させることができるようになります。このほか、スティック操作を検知することもできますし、独自の小さいライブラリを作ってゲームパッドからの入力を処理することもできます。詳しくは、Desktop gamepad controls をご覧ください。

特殊な操作方法

さらにもっと進んで、リビングにある大型 TV のリモコンを使ったり、ラップトップの前で手を振ったり、食材とPCを線で繋いでその食材を押したりすることで、ゲームをプレイすることも可能です。

例えば、Panasonic 製の TV リモコンはキーボードイベントを再利用しているので、対応が非常に簡単です。リモコンの方向矢印はキーボードのカーソルキーと全く同じコード（37、38、39、40）を使用しているので、すぐに対応できます。リモコン特有のボタンについては、こちらに一覧がありますので、詳細情報とともにご覧ください。

また、リモコンのボタンを押す代わりに、Leap Motion 機器の機能を使用して自分の手の位置や他のパラメーターを検知することで、何にも触れることなくプレイヤーの機体を操作することもできます。あらかじめ定義されている loop 内で、手に関する情報を取得できるので、

Leap.loop({
    hand: function(hand) {
        horizontalDegree = Math.round(hand.roll() * toDegrees);
        verticalDegree = Math.round(hand.pitch() * toDegrees);
        grabStrength = hand.grabStrength;
    }
});

それを使用してプレイヤーの位置を更新します。

function draw() {
    // ...
    if(horizontalDegree > degreeThreshold) {
        playerX -= 5;
    }
    else if(horizontalDegree < -degreeThreshold) {
        playerX += 5;
    }
    if(verticalDegree > degreeThreshold) {
        playerY += 5;
    }
    else if(verticalDegree < -degreeThreshold) {
        playerY -= 5;
    }
    if(grabStrength == 1) {
        alert('BOOM!');
    }
    // ...
}

その他にも、Unconventional controlsでは、 ドップラー効果や Proximity API、MaKey MaKeyなど興味深い操作方法の実装方法を紹介しています。

まとめ

最近は、HTML5 ゲームをプレイするのに使える機器がますます増えています。ご自身の腕時計も使えるかもしれませんし、はたまた音声認識によるウェブゲームも良いかもしれません。まさに、可能性は無限です。覚えておいて頂きたいのは、多くの操作方法に対応しているほど、ゲームにとっては良いことだということです。なぜなら、幅広い種類の機器を用いて、どんなプラットフォームでもプレイ可能になるからです。ぜひ、ブラウザがもたらす可能性を存分に活用しましょう。

[この記事は “Introducing debugger.html” の抄訳です]

debugger.html は Mozilla の作成したモダンな JavaScript デバッガで、React と Redux を使って実装されています。これは Firefox の開発ツールに組み込まれているデバッガを置き換えるためのプロジェクトで、今年の初めに始まりました。また複数のターゲットに対してデバッグできることや、単体での動作も目的としています。

現在は Firefox、そして実験的な機能として Chrome、そして Node に接続し、デバッグを行えます。Firefox への接続には Mozilla のリモートデバッグプロトコル (RDP) を、Chrome と Node への接続には Chrome の RDP を利用しています。

このプロジェクトは GitHub で公開されています。またモダンなフレームワークと、ツールチェーンを利用しています。多くの開発者にとって魅力的で、簡単に見つけられるようになっています。

debugger.html

debugger.html のユーザーインタフェースは、ソースパネル、エディタパネル、サイドバーの 3 つに分かれています。

• ソースパネルには、ソースコードがツリー状に表示されます
• エディタパネルには様々なソースファイルの表示が可能です。またソースコードを整形して見やすく表示する機能やブレークポイントの設定機能も持っています
• サイドバーには、現在設定されているブレークポイントが表示されます。プログラムがブレークした時には、その時点でのコールスタックと、変数が表示されます
  • 一時停止、ステップオーバー、ステップイン、ステップアウト、復帰といった、デバッグのための機能を提供します
  • 実行が一時停止されると、その時点でのコールスタックがコールスタックパネルに、スコープパネルには変数がツリー状に、それぞれ表示されます

はじめかた

debugger.html を使うには、まず GitHub からコードをチェックアウトし、 Getting Started を読むところから始めましょう。

すぐ使い始めたいなら、次のコマンドを実行してください：

npm install - Install dependencies
npm start - Start development web server
open http://localhost:8000 - Open in any modern browser

8000 番ポートへアクセスすると、デバッガーが表示されます。デバッグ対象が選択されると、そのターゲットに対し接続し、リモートデバッグを開始します。これには、ターゲットにいくつかの項目を設定しなければなりません。例えば MacOS 上で動作する Firefox に接続する場合には、次のコマンドを実行してリモートデバッグを許可する必要があります。

$ /Applications/Firefox.app/Contents/MacOS/firefox-bin --start-debugger-server 6080 -P development

Chrome や Firefox で利用するその他オプションはこちらを参照してください。

Node 上で動くコードをデバッグするには、v6.3.0 以上の node.js が必要です。inspect オプションをつけて Node を起動すると、デバッグができます。例えば myserver.js をデバッグするには、次のように実行します。

$ node --inspect myserver.js

詳細は Getting Started を参照してください。

Firefox の開発ツールとの関係

Firefox に組み込まれている開発ツールとの統合を進めています。最初の統合が終わり、Nightly 版で利用できるようになっています。

開発に参加するには

このプロジェクトは開発の途中です。皆様の参加は心から歓迎します。一緒に最高のデバッガーをつくりましょう。開発へ興味をお持ちの方は、まず貢献のための手引きをごらんください。

Bryan Clark について

Firefox 開発ツールのプロダクトマネージャ。

Twitter：@clarkbw

Bryan Clark によるその他のドキュメントはこちら

この記事は “What’s new in Web Audio?” の抄訳です。

Web Audio API は以前開発中です。つまり新しいメソッドや属性の追加、名称の変更、入れ替え、そして削除もありうるということです。

この記事では 2015 年初頭の時点からの Web Audio と、その Firefox における実装との変更点についてまとめます。参照しているデモは Firefox の Nightly 版で動作します。リリース版や Developer Edition では対応していない変更点もありますから、ぜひ Nightly 版で試してください。

API の変更

破壊的なもの

DynamicsCompressorNode の reduction 属性は AudioParam ではなく float となりました。その結果、compressor.reduction.value ではなく compressor.reduction を参照することで、値を読み出せるようになりました。

この値は入力シグナルに対して適用される減衰量を表します。以前よりリードオンリーの値であり、スケジュールされた値の変更が必要ないため、AudioPArame ではなく float への変更は妥当なものでしょう。

ブラウザのサポートするのが AudioParam なのか、それとも float なのかは、reduction の value 属性を参照することで判断できます。

if(compressor.reduction.value !== undefined) {
  // old style
} else {
  // new style
}

こちらでは、ドラムループが再生され、それに応じて reduction 属性の値が変化する様子がみられます。この値はトラックの音の大きさに合わせて変化しています。またブラウザがサポートする API のバージョンの判定方法も、併せて確認できます。

新しい属性とメソッド

AudioContext へ追加されたライフサイクル管理用メソッド

AudioContext の生成のコストは高かいため、suspend()、resume()、close() の 3 メソッドが追加されました。

これらのメソッドを利用することで、音声処理を必要になるまでサスペンドしたり、AudioContext が必要なくなった場合に close() を呼んでリソースを解放するといったことが可能になりました。

AudioContext がサスペンドされた場合、音声は再生されません。レジューム時にはサスペンドされた位置から再生されます。詳細については、suspend() の解説を参照してください。

これらのメソッドの利用例は、こちらのデモで見られます。

正確になった AudioNode の disconnect()

disconnect() を呼ぶと、接続されている全てのノードから切り離されてしまったため、特定のノードだけを選択的に切断することはできませんでした。

望まれる切断方法が多様化したため、使い方にあわせて disconnect() メソッドをオーバロードできるようになりました。

• disconnect()：全てのノードへの接続を切る（既存の機能）
• disconnect(outputNumber)：指定された出力チャンネルから、ノードへの接続を全て切る
• disconnect(anotherNode)：指定されたノードへの接続を全て切る
• disconnect(anotherNode, outputNumber)：このノードの outputNumber で指定されたチャンネルから anotherNode への接続を全て切る
• disconnect(anotherNode, outputNumber, inputNumber)：このノードの outputNumber で指定されたチャンネルから、anotherNode の inputNumber で指定されるチャンネルへの接続を全て切る
• disconnect(audioParam)：このノードから指定された audioParam への接続を全て切る
• disconnect(audioParam, outputNumber)：このノードの outputNumber で指定されたチャンネルから、audioParam への接続を全て切る

これらの切断に関する処理について理解するには、AudioNode の仕様を読むことを強くお勧めします。また変更が行われた理由については、こちらの議論を参照してください。

OfflineAudioContext への length 属性の追加

この新しい属性の値は、OfflineAudioContext の初期化時に実行されるコンストラクタの引数によって決まります。そのため、その値を別の変数に保存する必要がなくなりました。

var oac = new OfflineAudioContext(1, 1000, 44100);
console.log(oac.length);
>> 1000

こちらのデモではこの属性の使用例と、ゲインエンベロープを利用した音声の生成例が見られます。

AudioBufferSourceNode への detune 属性の追加

これは OscillatorNode の detune 属性と同様のものです。既存の playbackRate 属性よりも正確にサンプリングした音声を調整できます。

PannerNode に AudioParam 型の属性 position と orientation の追加

AudioParam 型の属性が追加されました。これらを利用することで、setPoistion() や setOrientation() を呼び続けなくても、それらの変化を自動化することができます。

StereoPannerNode の pan 属性はすでに AudioParam になっています。そのため音声のパンニングを扱うノードのは全て、自動的にその位置に関する属性を変更できるようになりました。これはモジュラーシンセを作るのに、とても便利なものたちです。

しかし AudioListener の位置と向きに関する属性を自動的に変化させることは、まだできません。つまりこれらの値を時間に応じて変化させるには setPosition() と setOrientation() を定期的に呼び出す必要があるのです。この問題は Bug #1283029 にファイルされています。

PeriodicWave の初期値指定

PeriodicWave オブジェクトを作成する際に、オプションをオブジェクトで渡せるようになりました。

var wave = audioContext.createPeriodicWave(real, imag, { disableNormalization: false });

比較のため、以前の書き方を載せておきます：

var wave = audioContext.createPeriodicWave(real, imag);
wave.disableNormalization = false;

将来的には、ノードを作成する全てのメソッドで初期値を渡せるようになります。またコンストラクタも利用できるようになるため、GainNode の作成もこのように行えます：new GainNode(anAudioContext, {gain: 0.5});。 これで初期化が必要な Web Audio のコードをより簡潔に書けるようになります。メンテナンスするコード量が減ることは、常にいいことですよね！

新しいノードの追加：IIRFilterNode

BiquadFilterNode では力不足と感じた場合、IIRFilterNode を使ってカスタムフィルタを作成すると良いでしょう。

AudioContext の createIIFilter() メソッドに、フィードフォワードとフィードバックの二つの係数を配列で与えることで、フィルタを作成できます。

var customFilter = audioContext.createIIRFilter([ 0.1, 0.2, ...], [0.4, 0.3, ...]);

このフィルタノードのパラメータを自動的に変化させることはできません。つまり一度作成したら、その値は変更できません。そのような変化をさせたいのであれば、BiquadFilter を利用し、AudioParam で指定できる Q / detune / frequency / gain の各属性を適切に設定することになります。

これらの違いについては仕様を読むと、より理解できるでしょう。また Digital Filter Design も便利なツールです。ここではフィルタのデザインとフィルタの可視化が可能で、feedforward と feedback を含む使用可能なコードが生成されます。

メソッドチェーン

書きやすさのために、いくつかのシンタックスシュガーも追加されました。

connect() メソッドは接続先のノードを返すようになったため、複数のノードの接続を簡単に書けるようになりました。

以前：

node0.connect(node1);
node1.connect(node2);
node2.connect(node3);

今：

node0.connect(node1).connect(node2).connect(node3);

また AudioParam の自動化メソッドも呼び出し先のノードを返すようになったため、メソッドチェーンを行えるようになりました。

以前：

gain.setValueAtTime(0, ac.currentTime);
gain.linearRampToValueAtTime(1, ac.currentTime + attackTime);

今：

gain.setValueAtTime(0, ac.currentTime)
  .linearRampToValueAtTime(1, ac.currentTime + attackTime);

これから

Web Audio ワーキンググループは AudioWorklet に関する仕様の記述をほぼ終えています。これは AudioWorker の新しい名前です。これは ScriptProcessorNode を置き換えることになっています。これは ScriptProcessorNode が開発者が定義した任意の音声処理を UI スレッドで行うため、パフォーマンスの面で改善の余地があったためです。

AudioWorklet と関連するオブジェクトを定義し、仕様に追加するプルリクエストのマージが最初に行われるでしょう。その後、各ブラウザベンダが AudioWorklet の実装に入ります。

Firefox：パフォーマンスとデバッグにおける改善

3 人のエンジニア（Karl Tomlinson, Daniel Minor and Paul Adenot）の 6 ヶ月以上の奮闘により、Firefox の Web Audio に関するパフォーマンスは改善されました。実践的な面から見ると、音声に関するコードは Chrome よりも同等以上のスピードで動作するようになりました。唯一の例外が AudioParam に関連するもので、そのパフォーマンスはまだ良いとは言えません。

同様にメインスレッドが重たい時によく起きていた ScriptProcessorNode の遅延も少なくなくなりました。これはコンソールエミュレータのようなアプリケーションには大きな改善です。低遅延はエミュレーションの信頼性を高め、その結果として多くのゲームを楽しめるようになるからです。

より深い話としては、DSP カーネルの計算にアセンブラレベルでの最適化が行われました。ARM と x86 の SIMD 命令の長所を利用して、パンニングやゲインの調整といった簡単な計算で、複数の値を並行に計算するようになりました。これによってコードの実行が高速かつ効率的になり、モバイル環境では特に重要なバッテリー消費もより少なくなりました。

また MediaElement ノードで発生する　cross-origin エラーが開発ツールのコンソールへ表示されるようにもなりました。以前はこのエラーが報告されないまま失敗するため、コードが止まる理由を考えるのが大変でした。この変更によって、その原因コードの特定が簡単になりました。

これら以外にも多くのバグが修正されました。ここに書くには多すぎるくらいですが、こちらのリストでそれらを確認できます。

Soledad Penadés について

Sole は Mozilla の Developer Relation チームの一員で、Web で素晴らしいものが作られるのを助けています。なかでもリアルタイムに関するものが好みです。irc.mozilla.org の #devrel でコンタクトできます。

• Web サイト：soledadpenades.com
• Twitter：@supersole

Soledad Penadés によるその他の記事はこちら。

この記事は “Developer Edition 50: Console, Memory Tool, Net Monitor and more” の抄訳です。

Firefox Developer Edition のバージョン 50 が公開されました。今回の更新では、スクリプト由来のリクエストのモニタや、IndexedDB に保存されているデータの操作など、多くの点で改良がなされています。これ以外にずっと欲しかった機能も紹介します。

コンソール

待ちわびた機能がついにやってきます。その機能とはソースマップです。この機能は最終のテスト段階で標準では off になっていますが、ぜひ試してフィードバックを送ってください。

ソースマップが実現の困難な機能であった理由については、James Long による解説記事があります。そちらをご覧ください：On the Road to Better Sourcemaps in the Firefox Developer Tools

そんな困難な機能の実装がどうして始まったか、興味はありませんか？Joe Walker によると、その理由は次のようになるそうです：

インターンは背景知識を十分に持っていない場合があって、バグの難しさを見誤ることも多い。その結果、本当に難しいバグにチャレンジすることになってしまうことも、ときおりある。ま、それがインターンなんだけどね。

解決をした Firefox の開発ツール担当インターン Jaideep Bhoosreddy に大きな感謝をしたいです。

ソースマップを利用することで、ダウンロード時間の短縮のために JavaScript ファイルを圧縮したり、TypeScript や CoffeeScript といった他のフォーマットから変換して JavaScript を作成することが可能になり、しかも元のファイルとの関係性も維持されるためデバッグが簡単になります。

デバッガはすでにソースマップに対応していますが、コンソールは今まで対応していませんでした。その結果、出力されたログに含まれるファイルや行番号といった位置は、変換後の JavaScript ファイルのものとなってしまって、ほとんど利用価値がなくなってしまいます。

しかしそれも過去のことです。、コンパイル後のものではなく、オリジナルのソースファイルの位置がコンソールに表示されるようになります。次の例は CoffeeScript ファイルの位置を表示しています：

ソースマップに対応したコンソール

コンソールのソースマップ対応機能は標準ではオフになっており、有効にするには設定を変更する必要があります。これはソースマップの作成に利用したツールにごとにいくつかの実装があるため、それらの幾つかをテストしたいと思っているからです。これが現在の状況です。

コンソールをソースマップに対応させるには

ソースマップに対応したコンソールを利用するためには、以下の手順に従って設定を変更します。

• URL バーに about:config と入力する
• devtools.sourcemap.locations.enabled を検索する
• その項目をダブルクリックし、値を true に変更する
• about:config を閉じ、コンソールを再び開く

何かおかしい点を発見したら、Twitter で @firefoxdevtools に宛ててつぶやくか、IRC の #devtools チャンネルでご相談ください。

ネットワークスタックトレース

Firefox Developer Edition バージョン 50 では、HTTP ログからリクエストを送信した際のスタックトレースが見られるようになりました。この機能は標準で利用できます。

メモリツール

メモリツールも標準で利用できるようになりました。デバッグとパフォーマンチューニングには欠かせないツールです。これを利用することで、メモリリークの発見と修正が簡単になります。このツールの詳細については、MDN の記事、もしくは Hacks の “Firefox’s New Memory Tool” という記事をご覧ください。

ネットワークモニタ

Firefox バージョン 49 で、”Cause” 列が追加されました。ここにはネットワークリクエストの発生理由の種別が表示され、可能であればスタックトレースも表示されます。スタックトレースはポップアップで表示されるのですが、今回の更新でここに、XHR や Promise、setTimeout といった非同期通信時のフレームが表示されるようになりました。ちょうどデバッガにおけるスタックトレースパネルと似たものとなっています。

また列のヘッダをクリックすることで、通信ログを原因ごとに並び替えられます。これは fetch によって発生したリクエストを早く探したい、といった場合に便利な機能です。

JSON ビューワ

JSON ビューワも改善され、よりスマートにデータを表示するようになりました：

• 空の配列は [] と表示されるようになりました。以前は [0] と表示されていましたが、今回の変更で空のオブジェクトの表記である {} と対応するようになりました
• 他の属性表示と同じく、オブジェクトの属性と値との間にコロンがはいるようになりました

ストレージインスペクタ

Mike Ratcliffe と Jarda Snajdr の泥浴によって、ストレージインスペクタも改良されました。その結果、コンテキストメニューから IndexDB 中の項目を 1 件ずつ削除できるようになりました。

about:debugging

Web 開発における次のビッグウェーブといえば、Service Worker でしょう。オフライン時の機能や、プッシュ通知といったネイティブアプリの持つ機能を備えた Web アプリである Progressive Web Apps を作るには、Service Worker の提供するツールを利用します。Firefox では、about:debugging#workers というページで登録された Service Worker の管理できます。今回の行為新で、このページで各 Service Worker が利用するプッシュ通知のエンドポイントも表示されるようになりました。またテスト用の通知を送るためのボタンも併せて追加されています。

その他の変更点

アイコン：開発ツール内のアイコンが一貫性とシャープさが出るように変更されました。

Firefox 49 でのアイコン

Firefox 50 でのアイコン

WebAssembly：Luke Wagner が以前のブログポストで述べています：

WebAsssembly は策定が進んでいる標準の一つで、その目的は安全性とポータビリティを維持しつつ、サイズとロード時間の面で効率的なバイナリフォーマットの定義です。

デバッガはすでに WebAssembly ファイルにも対応しています。またシンタックスハイライトもできるようになりました。

シンタックスハイライトされている WebAssembly ファイル

最後に小さいけれど便利な変更点を一つ：スタイルエディタを無効にできる機能が追加されました。これでスタイルエディタのアイコンが占めていたタブ上のスペースを節約できます。

以上で Developer Edition バージョン 50 の機能紹介は終了です。最新版をダウンロードして、フィードバックを送ってください。最後に今回追加された多くの改善に貢献されたすべての人に大きな感謝を示したいと思います。ありがとうございました。

開発ツールはスタンダードな HTML、JavaScript、CSS で開発されています。フロントエンジニアとしての経験があれば、その開発に参加できます。開発ツールの開発に興味をお持ちの方は、まず http://firefox-dev.tools/ にある簡単なバグから始めてみてはいかがでしょうか。参加はいつでも歓迎します。

Nicolas Chevobbe について

• Webサイト：nicolaschevobbe.com/
• Twitter：@nicolaschevobbe

Nicolas Chevobbe による他の記事はこちら