CanvasとBitmapとよもやま話

久しぶりにフロントエンド寄りのこと。

ウチの会社の制作本部の人達と久しぶりに飲みに行ったので、彼/彼女らの仕事の進め方みたいなものを聞いてきた。一般的なWebサイト制作はもちろん、FlashやJavaScriptなどの技術力も僕より数倍上な人達だ。大きな組織の内でプロのデザイナーとしてたくさんの人と競争し続けてきたわけだから優秀で当たり前なのかもしれない。趣味程度にやってる僕なんかとは違う。

* CanvasとBitmapについて
彼らはしばらくCanvasを使ったアニメーションやゲームなどの案件に注力することになるらしいが、どれだけ正確に作業工数の見積もりができるかが大切だと言っていた。大組織ならではのお金が見え隠れする面白い話も聞いたけど詳しくは書けない。。ただ工数に関して言えば、例えばアニメーションで利用する機能として、HTML5のCanvasもFlashのGraphicsも moveTo() や lineTo() など同じ名前/機能のAPIが提供されている。コードレベルでのFlashからCanvasへの移植作業など彼らにとってはただのタイピングに過ぎないようだが、クロスブラウザ対応の方はやはりある程度まとまった時間を取られてしまうらしい。

大事なのはそのクロスブラウザ対応にかける工数の見積もり。彼らはそれぞれ独自に考えた方法で工数を計算しているらしいが、共通しているのはCanvasを使った案件でもクロスブラウザ対応に工数をたくさんかけるものとそうでないものがあるということ。Canvas上に描いた絵を動かすアニメーションなどには多く工数をかけるが、イメージエフェクト系のものにはあまりかける必要がない。普通に考えたら当たり前なんだけど、画像データ自体を操作する部分ではクロスブラウザとか関係ないわけだ。そもそもCanvasにはイメージエフェクト系のAPIは存在しない。pixel manipulationの項目にあるAPIは以下の4つだけ。

BitmapDataと比べると大きな違いがあることがわかる。
BitmapData – ActionScript 3.0 コンポーネントリファレンスガイド
実質的にCanvasでは BitmapData#getPixels と BitmapData#setPixels に該当する機能しか備えていないことになる。多くの人は機能が貧弱だと言っているが、画像処理は実質的にこの2つの機能さえあればなんでもできる。Canvasに colorTransform() や copyChannel() などがなくても実装すればいいだけなので問題にはならない。JavaScriptは必要最低限の機能だけを提供して自分は小さくシンプルなままでいることに努め、リッチな機能はjQueryなどの外部ライブラリに任せている。一方、ActionScriptは自分にどんどん機能を追加して太らせていく方針を採った。(追加する機能の種類が偏っている気はするけど、。)

難しいのはパフォーマンスの確保。JavaScriptにはWeb Workersという強力な機能が備っているが、いつどういった時に使うかが難しい。画像処理であれば、採用するアルゴリズムとサービスが許容する最大画像サイズから計算量を見積もってWeb Workersを使うかどうかを決める。画像処理部分の計算量が少ない場合、workerとのメッセージングのコストの方が高く付くため、常にWeb Workersを使うという選択は賢明ではない。両者の実装コストの違いに関しては、やはり彼女らにとってはただのタイピングに過ぎないだろうから聞くのは止めた。まぁ確かに、Flashで計算をフレーム分散する面倒くささと比べて、Web Workersのshared nothingな仕組みだと実装は楽だと思う。

せっかくなので、昔Flashで作ったものを工数を意識しながらCanvas(JavaScript)で書き直してみる。
2009年に書いたJitter Filter (Photoshopの [フィルタ] > [表現技法] > [拡散] と同じ効果フィルタ) をCanvasに移植。これはVectorを使って実装されているので、コンテナ内の実データの配置がCanvasの getImageData() で得られるものとは全く違うところに注意、計算量は少ないのでWeb Workersは使わずに実装する。

Demo: Jitter Filter implementation on Canvas

特にクロスブラウザ対応をしなくても主要なモダンブラウザで動作することは確認。画素値が255を超える部分と画像データを指すインデックス値がコンテナサイズを超える部分、つまり境界値テストさえしっかりやればイメージエフェクト系のテストは大丈夫。QAテストをパスするのに必要なテスト項目を如何に速く列挙できるかが大切らしい。

* HTML5の良いところ
彼女らの意見は僕と全く同じ意見だった。HTML5の良さは文書の高度な構造化方法が提供されたこと。WWWにおけるリソース、つまりHyperText文書としての表現方法の幅が大きく広がったのだから喜んで受け入れよう。

* 僕が聞きたかったこと
正直、FlashとかHTML5とかはどうでもよくて、この人達のような制作サイドのエース達が僕らインフラエンジニアについてどう思っているのかが一番知りたかった。「キミたちのおかげで私たちがいっぱいサイト作れるんですよー」みたいなのは本心なのだろうか。デザイナーの人が”テンプレート”とか華麗に使いこなすのを僕は知ってるから、たぶんこれもテンプレートだとは思うんだけど、。

あわせて読む:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です