マークアップであること

先日の記事にコメントを折角貰ってたのにスルーしていました‥‥。ごめんなさい。

こないだの記事でCanvasをこき下ろしましたが、争点は標準・非標準だとは思っていません。そもそも技術規格は競うものであって標準は無いと思っています。また、ラスターorベクターでもありません。大事なのは「どっちが速く描けるのか」というです。

私が先日のIE9の発表で感銘を受けたのは、MSがずっと言っていたCanvasの否定的発言がハッタリだけじゃなかったこと、マークアップのアクセラレート（SVG）による抽象化がHTMLの本筋だと技術で見せつけたこと、です。

API階層が違う

SVGはラスタも含む画像のドキュメント表現規格だと思っています。CanvasはWindowsでいう素のGDI+の描画をできるよ、という事で、ラスター画像ならなんでもできるというのは正しいのですが、どう考えてもマークアップではありません。APIの階層的に異なる技術です。

10倍は狙えたけども

JavaScriptが10倍早くなりましたよ、だから速度を生かせる場としてCanvasを用意しましたよ。というのは流れとしてはありだと思っています。ですが、CanvasはJavaScriptに依存しすぎています。JavaScriptが行き詰まれば同時に限界を迎えかねません。

JavaScriptの言語としてのウィークポイントはマルチスレッドが不可能な仕様であること。もっと関数言語的な設計であれば並列化抽出も可能ですが、言語としての扱いやすさを優先してるために現状の仕様で固定されています。今後もおそらく10年単位で規格はいじられないでしょう。

そうなるとマルチコアの恩恵を受けられない。WebWorkerで並列化は出来ますが、開発者が並列化を意識せずに使えるようなものではないです。ましてやGPUレベルのメニーコアの恩恵を受けるのは非常に難しいでしょう。Canvasの基本設計には、末端開発者の相当な努力が必要となるか、もしくは努力でどうにも出来ない壁があります。後10倍早くなるかもしれませんが、1000倍・10000倍は無い。そういう位置づけの技術だと思います。

マークアップ描画は並列化余地が大きい

一方、SVGは宣言言語であり、JavaScriptとは切り離されたところに描画層が存在します。もともと非常に野心的な規格ですが、ベクター描画を取り扱うため規格制定時にはその描画の重さがどうしても表面化してしまう結果となりました。Flash対抗でしたがAdobeの身軽さもあり、次第に取り残される結果になったと考えています。

しかし、描画のためだけのマークアップであることは、独自の描画最適化余地が非常に大きいことも示します。今日ではGPUに丸投げして万のオーダーの高速化が可能です。JavaScriptとは切り離されているため、JavaScriptの限界に左右されることもありません。

API階層をまたぐメリットとデメリット

速度最適化の可能性は、HTMLブラウザレベルでは一番大きな階層として「描画層」「マークアップ層」「JavaScript層」に分けられます。この3つは独立して高速化の余地があり、事実最近のモダンなブラウザはこの階層でプロセスを分けていることが多いです。

しかし、CanvasはJavaScriptと描画を直接結びつけてしまっています。これはどちらかが必ずボトルネックになる事を示し、言語仕様の制約で最終的にJavaScriptが足を引っ張る可能性が高いはずです。一方、処理の総量は階層を結びつけることでかなり減らせますので、一時的には処理速度の向上が見込めます。

これはあるべき論ですが、「JavaScriptはシナリオ進行に徹し、描画本体はシステムに任せるべき」だと思っています。これがJavaScriptに求められた要求であり、仕様もその観点から見て非常に美しいと思ってます。マークアップ描画側の高速化の伸び代に無限の可能性があるならそちらに任せるべきで、「いつかはマークアップに座を譲る技術」とCanvasを見ていました。

10年先の予定だった？

後は「いつか」が5年先か、10年先か、という話だったのですが‥‥。ここでIE9が「１年後？にはお前の描画速度を抜かしてやる！」と刃を突きつけた状態、であるならWebkit陣営は大幅な戦略見直しを迫られる。そういう風に、考えました。MSにはSilverlightの技術があります。SVG実装は内部的にはSilverlightでやってることの焼き直しですから実際問題として速度的には追い抜きかねない状態でしょう。

Webkit陣営は「SVGの描画速度がCanvas実装を追い抜く」可能性を視野に入れなければならなくなった。標準争いではなく技術競争になってるから面白い、と感じたのです。