Canvasのベンチマークテストを作って速度を比較してみた

HTML5

はじめに

Canvasのパフォーマンスを測定するベンチマークプログラムはそこら中に転がっていますが、ほんの一部分の測定だったり、逆に中身が複雑過ぎたりと僕が希望するようなものが見当たらなかったので、自分で作って各ブラウザで測定してみました。

測定したブラウザのバージョンは以下です。

Chrome Firefox Safari Opera
9.0.570.1 dev 3.6.12 5.0.2 10.63


ベンチマーク

作成したベンチマークプログラムは単位時間で描画関数を何回繰り返して実行できるかという単純なものです。実行中に描画される絵のいくつかを載せておきます。

hlinebezierfill_arcfill_starsimage_scaleradial_gradient

以下に全測定項目の概要を記します。

  • hline ひたすら水平方向の直線を描きます。
  • vline 垂直方向の直線
  • line 任意方向の直線
  • rect 矩形描画
  • fill_rect　矩形の塗りつぶし
  • lines 任意方向の直線
  • arc 円弧
  • fill_arc　円弧の塗りつぶし
  • bezier　ベジエ曲線
  • fill_bezier　ベジエ曲線の塗りつぶし
  • quad　quadraticCurveTo１回の描画
  • curves　複数の連続quad描画
  • fill_curves　curvesの塗りつぶし
  • stroke_star　多数の星型の回転を含む描画
  • fill_star　上記星型の塗り潰し
  • transform　translate-rotate-scale変換
  • image　イメージ描画
  • imge_scale　イメージの拡大・縮小
  • image_rotate　イメージの回転
  • linear_gradient　線形グラデーション
  • radial_gradient　円形グラデーション
  • text　文字列描画
  • clip　星型のクリップ（イメージと直線）


以上の基本ベンチマークに加え、SpiralStarsと名付けたサンプルデモの実行速度(fps)を計測しました。

左記のようなアニメーションが表示されます。アルゴリズムは非常に単純ですが、見ていてちょっと面白いです。


結果

ベンチマークとSpiralStarsの結果は以下のようになりました。各項目の測定結果は項目によって大きな違いがでないように、適当な重み付けをしています。総合的なTotal Scoreはそれらの結果を調和平均したものです。

Chromeが断トツに高速です。昔、SkiaとCairoの速度比較をしたことがありますが、Skiaの方がかなり高速でした。恐らく、今回の結果もV8の高速性もさることながら、Skiaによるところが大きいのではないかと思います。

測定結果 Chrome Firefox Safari Opera
Total Score (Harmean) 2.02 0.737 1.03 1.00
SpiralStars (fps) 35.2 9.4 9.8 12.7


実行プログラム

例によってソースを以下のところに置いておきました。ここでは言及しませんでしたが、半透明のα値のある描画モードの測定もできるようになっています。よろしかったら実行してみてください。

終わりに

ChromeのSkiaは速いということは以前から知っていましたが、SpiralStarsを作ってこれ程まで違いがあるとは予想外でした。Chrome Experimentsはいつもウォッチしているのですが、Firefoxでもそれほど違いなく動作するものが多いように感じられます。

SpiralStarsはChromeで実行すると目まぐるしい速度で描画されますが、ティアリングが発生しているのがわかります。ダブルバッファを使えばこのようなティアリングは軽減されると思いますが、Canvas APIにはダブルバッファを使うための簡単なAPIがありません。Canvasを２枚使って切り替えたりするなどの工夫が必要になります。しかし、たとえそのような実装をしたとしても、ディスプレイのVSyncに同期して描画するということができない限り、ティアリングを完全になくすことはできません。これについては、別の機会で触れたいと思います。

いずれにしても、Canvasは近いうちにハードウェアアクセラレータにより描画されることになるでしょう。そのときは、今回測定したベンチマークの結果は大きく異なることになると予想されます。

Canvasのイメージ拡大描画について比較してみた

HTML5

CanvasのdrawImage APIは下図のように、ソースイメージ中の任意の矩形領域をCanvas領域中の任意の大きさの矩形にマッピングできます。

context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)

このAPIによって、イメージの部分領域の縦・横方向の拡大縮小が自由にできるようになっています。

今回は、この拡大機能がちょっと気になったので以下のブラウザの各バージョンで調べてみました。

Firefox Chrome Safari Opera
3.6.11 8.0.552.11 dev 5.0.2 10.63

調べたのは、下のような赤と青が１ピクセル毎に交互に描かれているイメージを拡大したときの補間の表現です。

このイメージを下記表のように拡大してみました。

5倍 10倍 20倍
40倍 80倍 160倍
320倍 640倍 1280倍

以下のような結果になりました。

Firefox

きれいに補間されてグラデーションになります。

Chrome

グラデーションが縞模様になっています。また、拡大率が他と比較して低く、周辺の描画がちょっと変です。

Safari

Chromeと同じようにグラデーションが縞模様になっています。縞の幅がChromeより大きいです。

Opera

Firefoxと全く同じに見えます。


イメージをこんなに極端に拡大することはほとんどないため、特に問題はないと思いますが、ちょっと面白い結果です。ちなみに、imgタグで拡大したときのグラデーションも似たような結果になりました。

実際のコードはこちらをご覧ください。

一息ついたので、ちょっと仕事のことを

雑記

ここ１ヶ月ちょっとの間、製品化に向けたソフト開発の終盤で多忙を極めていたが、どうにか出荷できそうな見通しがついた。僕が担当したのは、全体で数百万行ある大規模ソフトの中の極一部に過ぎないが、今回の目玉となるネットと映像を使った新機能部分である。

このブログではJavaScriptについていろいろ書いているが、今の仕事では専らC++を使っている。ブラウザ上で実行するJavaScriptのコードであれば、同時にロードするのはせいぜい１万行程度であり、ちょっと修正して即実行というインタラクティブな開発が可能であるが、数百万行を超えると全体のコンパイルだけで30分以上かかってしまうため、そういうわけにはいかない。通常はもちろん部分コンパイルであるが、最後のリンクに5分くらい要してしまうのである。また、メモリが限られているからデバッグ環境を組み込むことができず、頼りとなるのはコンソールに出力されるログ、経験と勘、それと、現象から原因を合理的に推論する論理的思考である。とても原始的なスタイルだ。といっても、プログラミングを覚えた頃から派手なIDEなど使わず、Emacs一本でほとんどのことをしてきたから、自分の性に合っている。

開発は北米や欧州を含め、国内でも分散しており、同じ社内でありながら顔も見たことない人達とプロジェクト管理ソフト上でコミュニケーションしながら進めている。稚拙な英語でも何とか意図は伝わるし、まさにUMLやプログラム言語が共通言語であることも実感した。

開発したソフトは残念ながら欧州向けだ。具体的なことを書くことはできないが、日本でもこういうことができたらいいな、と安定してきたソフトを自らユーザとなって使っていてつくづく思うが、いろいろ難しいらしい。日本がますます世界から取り残されてしまうのではないかと心配になる。　

いずれにしても、自分の書いたソフトが製品内部に組み込まれて世の中に出て行き、多くの人に使われるというのはそれなりに嬉しい。はやりそれは実際にコードを書いている人間にしかわからないものだと思う。途中過程ではかなりの苦労もした。でも、好きだから苦にはならない。まとまったモジュールを一人でコーディングしているため、自分が失敗したらプロジェクトに多大な遅延と損害を与えるという、ほどよい緊張感の中、ちょっとした壁やトンネルもあったけど、プログラムを書くというのは、まさに自分自身との対話であり、人を知ることでもあるということを改めて思いました。

HTML5 Canvasのブラウザによって異なる微妙な振る舞いについてまとめてみた。

HTML5

はじめに

CanvasはHTML5とは切り離された独立した仕様(HTML Canvas 2D Context)になっているようですが、現状のブラウザ上でのCanvasのについて、普段はあまり気にしない微妙な振る舞いについて調べた結果をまとめてみました。

調べたブラウザの各バージョンは以下の通りです。

Firefox Chrome Safari Opera
3.6.8 6.0.490.1 dev 5.0.1 10.61

線を描く (lineTo)

ただの直線を描くだけのlineToですが、その単純なものにも、恐らく、多くの人が普段は気にしないような問題があります。それは座標値とアンチエリアスです。詳しく見る前に、実際の結果を示しましょう。下記のイメージ中に描かれている線は、いずれも線幅(lineWidth)が1の線です。



(左から、Firefox, Chrome, Safari, Opera)

どのブラウザでも同じように描画されているようですが、よく見ると、青の45度の斜め線がChromeとそれ以外では異なります。小さくてわかりにくいので、10倍に拡大して見てみましょう。この拡大もcanvas(イメージのキャプチャ*1 )を使っています。下図で、左がChrome以外で、右がChromeです。青の斜め線はChrome以外ではアンチエリアスされていますが、Chromeではされていません。




さららに面白いことに、これらの線はいずれも線幅が１であるにも関わらず、色が薄くて太く見えるということです。特に、上端の水平線の赤と左端の垂直線の緑はどちらも(2, 2)の座標から右方向と下方向に伸ばしている直線で座標値は整数値です。どうして２ピクセル分の幅になっているかというと、Canvs2Dの座標値はピクセルをベースにしているのではなく、あくまで数学的な意味でのものだからです。

つまり、原点(0, 0)はcanvasの左上ですが、左上のピクセル(の中央)が原点ではなく、左上のピクセルの左上の隅が原点になります。なので、整数で表される座標値は、ピクセルとピクセルのちょうど境界になるため、幅１であっても2ピクセル分に跨って描画されることになります。±0.5シフトしてピクセルの中央になるように座標を指定すれば水平・垂直の線は１ピクセル分だけの幅になります。

上の図で、4本の赤の垂直線のY座標は左からそれぞれ15.0, 18.3, 20.5, 22.7 になっていますが、20.5の場合ちょうどピクセル幅が１になっていることがわかります。

細い線を描く (lineWidth)

線の幅はGraphicsContext2DオブジェクトのlineWidthプロパティ指定して、その型はfloat(JavaScriptではNumberにマッピング)なので、幅が2.5の線や1より細い線などが表現可能ということになります。

先ほどの描画した線の幅を0.5に設定したときの結果を以下に示します。






Firefox(左)とChrome(右)

垂直の赤の線に注目してください。Y座標値がそれぞれ15.0, 18.3, 20.5, 22.7の垂直線であり、線幅が1のときは2ピクセルに跨るため太くなる結果になりましたが、線幅が0.5のときは15.0の線以外は1ピクセル内に収まる幅です。確かに、Chrome以外は1ピクセル幅の線として描画されています。Chromeの場合は、幅が1のときと同じまま全体的にアルファがかかったようになっています。そのため、１より細い線がChromeでは寝ぼけた感じになることがあります。

さて、１より細い線はアルファ値を小さくして透明度を上げて描画されていますが、これは実装上の動作であり、canvasの仕様ではそのようなことは規定されていません。事実上、アルファ値は0〜255の1バイトで実装されるので、線幅とアルファ値が線形関係になっていると仮定すると、線幅が1/255より細い線はアルファ値が0以下になり完全透明なので描画されないということになります。


実際に確認してみましょう。といっても、薄い細い線を１本描いてそれを目で見ても分かりません。イメージをキャプチャしてデータを調べれば分かりますが、ここでは別の方法をとります。つまり、線幅の間隔で平行な線でびっしりと埋めてどうなるかを見てみます。左図は幅１の線を赤と青を交互に１づつずらしながら描いたものです。この線の幅を小さくしてどうなるかを確認しました。線幅が小さくなると赤と青が混じり合って紫になりますが、さらに小さくすると突然描画されなくなる場合があります。


結果を以下に示します。

Firefox Chrome Safari Opera
1/256 1/128 1/255 ―

Firefoxは1/256を境界として描画されなくなります。Chromeは1/128のようです。Safariは全体的にアルファが下がって明確な境界は見つけられませんでした。Oparaは1/51200しても描画されました。


左図は線幅が1/64のときのChromeの結果です。格子状のパタンが表示されていますが、これはcanvasの背景にセットしたイメージです。Chromeの場合、細い線のアルファのかけ方が他と異なり、上書き(copy)方式のようなものになっているようです。

これまでの動作や以降の項目で登場するいくつかは下記のリンクから実際の動作を確認できます。

矩形とその塗りつぶし (rect, fill)

矩形を簡単に描画するrect()というAPIがあります。

The rect(x, y, w, h) method must create a new subpath containing just the four points (x, y), (x+w, y), (x+w, y+h), (x, y+h), with those four points connected by straight lines, and must then mark the subpath as closed. It must then create a new subpath with the point (x, y) as the only point in the subpath.

矩形を描いてその後、新しいパスを生成して位置を(x,y)にセットしろ、とありますが、この解釈の違いがブラウザで現れています。wとhは正数でなければいけないとは書かれていないので、負数でもよいと考えられます。そのとき(x,y)は矩形の左上とは異なる他の点になりますが、ChromeとSafariでは(x,y)が必ず左上になるように調整していると思われる結果になっています。

さらに、仕様からは矩形を描く線分の方向も読み取れますが、wとhを正または負に設定するすることで、時計回りや反時計回りの矩形を描画することもできます。しかし、ChromeとSafariでは頂点の値が調整されてしまうためか、常に時計回りで描画されるようです。

一方、Operaではw, hに負の数を指定するとINDEX_SIZE_ERR例外が投げられます。

以下の結果にその違いがわかります。







Chrome,Safari(左)とFirefox(中)およびOpera(右)

実際の動作は以下で確認できます。


なお、矩形領域の塗りつぶしは、線幅がゼロの線で囲まれた内側を塗りつぶすことですから、座標値がちょうど整数のときにアンチエリアスされることなく各ピクセルがピッタリ描画されます。左図は、5x5の大きさの矩形を左上座標を変えて描画したものです。アンチエリアスされているのは、座標が0.5の端数であるものです。

また、fill()による塗りつぶしのwinding ruleはnon-zeroのみがサポートされています。

The fill() method must fill all the subpaths of the current path, using fillStyle, and using the non-zero winding number rule.

影を描く (shadow)

Canvas2D APIは2Dなのに影を描画するという機能があります。利用シーンが多いため特別に用意された機能のように思われますが、ちょっと違和感があります。

影にはぼかし効果(blur)を指定できますが、図形やイメージ自体にblurが適用できないのは、ちょっと残念です。

この影の描画はChromeがちょと変な実装になっています。Chromeでは以下のような問題がります。

  • 図形をrotate()で回転すると影の位置自体も回転してしまう。
  • 図形にアルファを付けて薄くしても、影が薄くならない
  • 図形にグラデーションをつけると、影にもグラデーションがついてしまう
  • イメージに影がつかない

一方、Safariでは図形にグラデーションを付けると、影がつかないという問題があります。







Firefox/Opera(左)とChrome(中央)、およびSafari(右)

実際の動作は下記で確認できます。

クリップ境界のアンチエリアス (clip)

Chromeでは、clipでくり抜いた図形の境界がアンチエリアスされないという症状があります。






Chrome以外(左)とChrome(右)

直線に接する弧を描く (arcTo)

arcToの妙については下記の過去のエントリーで取り上げました。

Operaに変化があったようですが、相変わらず激しく変です。以前のOperaは左のような描画をしていましたが、今は右のようなものになっています。少しは顔らしくなったのでしょうか？




Composite

globalCompositeOperationはPorter-Duffの方法で合成されますが、ブラウザによって微妙に結果が異なります。なお、canvas仕様ではlighterというプロパティは定義されていても、darkerというプロパティは定義されていませんが、SafariとChromeでは実装されているようです。

Firefoxの結果を以下に示します。

下はOperaの結果です。copyとdarker以外はFirefoxと同じです。

下はSafariとChromeの結果です。両者は同じです。Firefox/Operaと比べて大きな違いがあるのがわかります。

Firefox系とChrome系のどちらが正しいかは、Porter-Duffがどう定義されているかを調べればよいわけですがWikipediaの図入り説明が分かりやすいでしょう。

これを見ると、どうやらFirefox/Operaが正しく、Chrome/Safariは間違っているようです。

PorterとDuffによるオリジナルの論文は下記から読むことができます。

ちなみに、下記のページが暫く前に、はてブがたくさん付けられたようですが、ブラウザで実行した結果を表示しているため、ブラウザによりに結果が異なることに注意が必要です。

実際の動作は以下から確認してみてください。

360度以上のarc

arcはstartAngleからendAngleまでの円周上の弧を描画するものですが、その角度が360度以上のときどうなるかは、仕様では以下のように明記されています。

If the anticlockwise argument is false and endAngle-startAngle is equal to or greater than 2π, or, if the anticlockwise argument is true and startAngle-endAngle is equal to or greater than 2π, then the arc is the whole circumference of this circle.

つまり、360度以上のarcは一周全部を描画する必要があります。Chrome以外では正しくないようです。fill()したときの結果も異なります。







Chrome(左)、Safari/Firefox(中央)、Opera(右)

実際の動作は以下より確認できます。

グラデーション

しばらく前までは、ChromeのRadialGradientが酷い状態でしたが、現在は問題は無くなっています。

テキスト (fillText, strokeText)

textBaselineプロパティで垂直位置のベースラインを指定できますが、Firefoxはhangingが正しくありません。alphabeticを指定したときと同じなので、実装されていないのかもしれません。

また、fillText()でSafariとOperaはアンチエリアスされますが、FirefoxとChromeはされません。strokeText()では全部のブラウザがアンチエリアスされていました。






Firefox/Chrome(左)、Safari/Opera(右)

おわりに

ブラウザ毎に異なるcanvasの細かい動作についてまとめてみました。canvas仕様はまだドラフトなので今の段階で100%準拠は期待できないとしても、ブラウザ間での動作の違いは解消して欲しいものです。

動作を確認するソースコードの説明は一切省略しましたが、殴り書きコードですが興味ある方は中身を覗いてみてください。

*1:getImageData()関数とcreateImageData()関数で実装。Operaでは後者の関数は実装されていない。(追記8/22)

1/9801=0.00010203040506070809

雑記

ハムスター速報(数学にまつわる興味深い話)で知ったのだけど、これは知らなかった。

bcコマンドで200桁まで計算すると、確かに98が抜けているだけで、01 02 03 04 ...と99まで連続している。

% bc -l
scale=200
1/9801
.0001020304050607080910111213141516171819202122232425262728293031323\
33435363738394041424344454647484950515253545556575859606162636465666\
76869707172737475767778798081828384858687888990919293949596979900

9801というのは(100-1)2であり、同じパターンでもっと大きい数までできる。

% bc -l
scale=4000
1/(1000-1)^2
# 結果を見やすく整理して書くと
0.
000 001 002 003 004 005 006 007 008 009
010 011 012 013 014 015 016 017 018 019
020 021 022 023 024 025 026 027 028 029
030 031 032 033 034 035 036 037 038 039
040 041 042 043 044 045 046 047 048 049
050 051 052 053 054 055 056 057 058 059
060 061 062 063 064 065 066 067 068 069
070 071 072 073 074 075 076 077 078 079
080 081 082 083 084 085 086 087 088 089
090 091 092 093 094 095 096 097 098 099
100 101 102 103 104 105 106 107 108 109
110 111 112 113 114 115 116 117 118 119
120 121 122 123 124 125 126 127 128 129
130 131 132 133 134 135 136 137 138 139
140 141 142 143 144 145 146 147 148 149
150 151 152 153 154 155 156 157 158 159
160 161 162 163 164 165 166 167 168 169
170 171 172 173 174 175 176 177 178 179
180 181 182 183 184 185 186 187 188 189
190 191 192 193 194 195 196 197 198 199
200 201 202 203 204 205 206 207 208 209
210 211 212 213 214 215 216 217 218 219
220 221 222 223 224 225 226 227 228 229
230 231 232 233 234 235 236 237 238 239
240 241 242 243 244 245 246 247 248 249
250 251 252 253 254 255 256 257 258 259
260 261 262 263 264 265 266 267 268 269
270 271 272 273 274 275 276 277 278 279
280 281 282 283 284 285 286 287 288 289
290 291 292 293 294 295 296 297 298 299
300 301 302 303 304 305 306 307 308 309
310 311 312 313 314 315 316 317 318 319
320 321 322 323 324 325 326 327 328 329
330 331 332 333 334 335 336 337 338 339
340 341 342 343 344 345 346 347 348 349
350 351 352 353 354 355 356 357 358 359
360 361 362 363 364 365 366 367 368 369
370 371 372 373 374 375 376 377 378 379
380 381 382 383 384 385 386 387 388 389
390 391 392 393 394 395 396 397 398 399
400 401 402 403 404 405 406 407 408 409
410 411 412 413 414 415 416 417 418 419
420 421 422 423 424 425 426 427 428 429
430 431 432 433 434 435 436 437 438 439
440 441 442 443 444 445 446 447 448 449
450 451 452 453 454 455 456 457 458 459
460 461 462 463 464 465 466 467 468 469
470 471 472 473 474 475 476 477 478 479
480 481 482 483 484 485 486 487 488 489
490 491 492 493 494 495 496 497 498 499
500 501 502 503 504 505 506 507 508 509
510 511 512 513 514 515 516 517 518 519
520 521 522 523 524 525 526 527 528 529
530 531 532 533 534 535 536 537 538 539
540 541 542 543 544 545 546 547 548 549
550 551 552 553 554 555 556 557 558 559
560 561 562 563 564 565 566 567 568 569
570 571 572 573 574 575 576 577 578 579
580 581 582 583 584 585 586 587 588 589
590 591 592 593 594 595 596 597 598 599
600 601 602 603 604 605 606 607 608 609
610 611 612 613 614 615 616 617 618 619
620 621 622 623 624 625 626 627 628 629
630 631 632 633 634 635 636 637 638 639
640 641 642 643 644 645 646 647 648 649
650 651 652 653 654 655 656 657 658 659
660 661 662 663 664 665 666 667 668 669
670 671 672 673 674 675 676 677 678 679
680 681 682 683 684 685 686 687 688 689
690 691 692 693 694 695 696 697 698 699
700 701 702 703 704 705 706 707 708 709
710 711 712 713 714 715 716 717 718 719
720 721 722 723 724 725 726 727 728 729
730 731 732 733 734 735 736 737 738 739
740 741 742 743 744 745 746 747 748 749
750 751 752 753 754 755 756 757 758 759
760 761 762 763 764 765 766 767 768 769
770 771 772 773 774 775 776 777 778 779
780 781 782 783 784 785 786 787 788 789
790 791 792 793 794 795 796 797 798 799
800 801 802 803 804 805 806 807 808 809
810 811 812 813 814 815 816 817 818 819
820 821 822 823 824 825 826 827 828 829
830 831 832 833 834 835 836 837 838 839
840 841 842 843 844 845 846 847 848 849
850 851 852 853 854 855 856 857 858 859
860 861 862 863 864 865 866 867 868 869
870 871 872 873 874 875 876 877 878 879
880 881 882 883 884 885 886 887 888 889
890 891 892 893 894 895 896 897 898 899
900 901 902 903 904 905 906 907 908 909
910 911 912 913 914 915 916 917 918 919
920 921 922 923 924 925 926 927 928 929
930 931 932 933 934 935 936 937 938 939
940 941 942 943 944 945 946 947 948 949
950 951 952 953 954 955 956 957 958 959
960 961 962 963 964 965 966 967 968 969
970 971 972 973 974 975 976 977 978 979
980 981 982 983 984 985 986 987 988 989
990 991 992 993 994 995 996 997 999 000
001 002 003 004 005 006 007 008 009 010
011 012 013 014 015 016 017 018 019 020

998 がないけれど、それ以外は999まで連続しているっぽい。

数学的意味はないと思うけど、久々にちょっと驚き。

ロボットとは何か　人の心を映す鏡

読書

ロボットとは何か――人の心を映す鏡 (講談社現代新書)

ロボットとは何か――人の心を映す鏡 (講談社現代新書)

マスコミにも大きく取り上げられたリアルな人型ロボットを開発している阪大の石黒教授の本。教授の外見にインパクトがあるが、それに負けず考え方もユニークだ。不気味なくらいリアルなものをTVで見て、なぜ女性ロボットなのか、ちょっとアブナイ方向へ行ってしまうのではないかと心配してしまったが、そんなことは本人も明確に意識しているわけで、また、女性であることの理由もちゃんと本書で説明されている。

ロボットとは何かは、すなわち、人間とは何かという哲学的な問題を探求するとと同じである。本書は、いきなり次の言葉で始まっている。

「人には心はなく、人は互いに心を持っていると信じているだけである」

かなり虚無主義的な表現であるが、人間とは何かをロボット工学者として探求した結果の結論であり、この言葉の真意は本書を読めば伝わってくる。

どうすれば人間のように振舞えるロボットを作ることができるか？それを追求した結果、

「ロボットの研究とは人間を知る研究である」

という結論に達したという。どのような研究分野でも究極の行き着く先は「人間とは何かを知る」ことであると僕自身感じているので非常に共感を覚える。

そして、

「ロボットは心を持てるか？」

という問題に対して、平田オリザとのロボット演劇を実践している。ロボットはいかにもロボットという形状のプログラム通りに動作するだけの機械であるが、観客の多くがロボットに心を感じたという。

心というものには実体はないが、人間なら誰もがその存在を感じるものである。しかし、それは自分自身では正確には知ることができず、

「自分の心も、他人の心も、観察を通して感じることでその存在に気がつく」

ということになる。これならば、心が何かは分からなくても、人間のように振舞うロボットに対して心を感じることが可能となる。

僕自身、認知科学や心理学に興味を持ち、純粋なソフトウェアだけで知能は可能だとかつては信じていた記号主義的な立場であり、ブルックスのような現実のロボットを使って環境と相互作用することの意味は分からなかった。百足ロボット如きに知能が生まれるわけがないと。

ところが、外見が非常に精巧にできたアンドロイドの研究が知能の問題を飛び越えて心の問題に迫っているのは大きなブレークスルーであった。遠隔操作型アンドロイドであるジェミノイドが心身問題にまで踏み込んだ研究の新たな方法論を提供したのはまさにパラダイムシフトであり、「世界の100人の生きている天才」で26位に選出されたのも頷ける。


ところで、アンドロイドが女性で、心がどうのこうの、ということになると、綾瀬はるか主演の映画『僕の彼女はサイボーグ』をどうしても思い出してしまう。タイトルはサイボーグだけど、実際にはアンドロイドだ。この映画、単純で面白みのないタイトル名でちょっと損しているんじゃないかと思う。初めはアイドルの単なるラブコメ映画と甘く思って見ていると、後半からの予想外の急展開が待っている。終盤でのストーリはじ〜んと心に沁みて泣けてくる。TVではちょっと天然キャラ的な綾瀬はるかを大いに見直したりした。

この映画でもアンドロイドと心の問題に触れている。２年以上も前の映画なので今更ネタバレということもないだろうし、複数回の鑑賞に耐え得る内容である。いや、むしろ1回見ただけでは見落としている伏線が多い。

僕であるジローがアンドロイドである彼女を好きになってしまうのであるが、それは一方的なものか、もしかしたら

「心が通っていると思うのは僕の錯覚なのではないだろうか」

と自問する。僕はこれほどまでに彼女を好きなのに、彼女の方は何も感じないというのは切なく苦しい。

「愛しているって言えないなら、私の心を感じる。心を感じることができると言ってくれたらいい」

とジローが言うシーンがある。「感じることができる」という表現がポイントであるが、人間であれば感じることに対して普通は可能動詞は使わない。アンドロイドの彼女にとって感じることも能力（徐々に発達した機能）の一つであり、感じなくてもよいから、せめて感じることができると言って欲しいと。ちょっと矛盾しているようだが、これは、論理学的にはメタな表現であり、いかにも人工知能的な表現である。

そして、大震災の時に、自らを犠牲にしてジローを救出し、

「わたし、あなたの心を感じる。感じることができる」

と言う。人間がロボットに心を感じる以上に、ロボットが人間に心を感じる方が高度なことだと思うが、心とは「観察を通して感じることでその存在に気づく」ものであるから、ジローが自分に対してとった行動を通してジローの心の存在に気づいたのである。

ところで、最後のシーンに登場する彼女が人間かサイボーグかという議論があるようだが、僕は何の疑問もなく人間だと思っていた。サイボーグだという意見の根拠は彼女がサイボーグが着ていたような服を着ていることと、「私はあなたの心を感じることができる」と言ったことである。しかし、それでも明らかに彼女は人間である。服については、瓦礫の町で彼女がシュルエットで登場するシーンであり、それが一瞬で彼女であることを視聴者が分からなければならない。そのためには、綾瀬はるかの豊満な体のラインが浮き出るような演出が必要だった。「感じることができる」については、ジローと過ごした過去の記憶は彼女自身のものではなく、サイボーグに埋め込まれた記憶チップを介して間接的に経験したものに過ぎないけれど、それでもあなたの心を感じることができる、と解釈できる。そして、何よりも彼女にとって１００年以上も昔のこの世界で、あなたと共に生きていくという覚悟のような決意と、サイボーグでは見せなかった満面の笑みが何よりの証拠である。

石黒教授のその後の本に『ロボットは涙を流すか　映画と現実の狭間』というのがある。まだ読んでいないが、「A.I.」や「ターミネータ」「サロゲート」など題材にしているらしい。映画の「彼女」は心を感じることはできても、涙を流すようにはプログラムされていなかったようであるが、石黒教授には是非この『僕の彼女はサイボーグ』も考察の対象に加えて欲しいところである。

AppleにとってHTML5とは何なのか？

Web

AppleのHTML5 and web standards[1]というサイトが物議を醸している。HTML5 ShowcaseにはHTML5ならこんな凄いことができる的なサンプルがあるが、Safari以外のブラウザではブロックされていて、Safariのダウンロードを誘導するポップアップが表示されるのである。確かにその先にあるデモを完全に動作させるためにはSafariが必要かも知れないが、これはいかがなものかと思う。かつてのMicrosoftのようなやり方を彷彿させるものであり、非常に危険な印象を受ける。

オープン市場で競争原理を軸とする企業であるからには、勝つための戦略を持つのは当然であるにしても、Webの世界ではそれが露骨すぎてはいけない。Appleの製品と開発環境は確かにすばらしいが、囲い込み戦略は時代錯誤であり、今後のWebの発展を阻害するなにものでもないと思う。

もっとも、このHTML5 Showcaseと同じものはSafari Dev Center[2]からもアクセスできる。そこではSafari以外をブロックすることはしていないので、他のブラウザでデモを実行することができる。内容にあまり目新しさはなく、OperaのHaavard記事[4]によるとHTML5を利用しているのはvideoとaudioくらいなものだそうだ。確かにソースをみると、Typography, Gallery, TransitionなどはCanvasではなくCSS3の機能を使っている。HTML5がどこまでを指すかの違いといえばそれまでであるが。

いずれにしても、問題のページが、たとえSafari（あるいはWebKit）固有の機能を使っていたとしても、Safari以外をブロックするのはよろしくないので、速やかに解除して欲しいと思う。

参照記事