3Dウェブへ向けたグーグルの取り組み--WebGLによる「O3D」再構築の可能性 - (page 3)

障害物はあるか

　この新しいアプローチの問題の1つは、パフォーマンスだ。

　O3Dに携わっているGoogleのプログラマーGregg Tavares氏は、2009年にメーリングリストでのディスカッションでその問題を提起している。

　「WebGLは、アプリケーションのシーングラフ（3Dオブジェクトのカタログ）の作成にあたってJavaScriptに100％依存しており、非常に特殊なケースや非常に高速なマシンを除いて、60Hzで数個以上の形状を描画する場合に深刻な問題が生じるだろう」。Tavres氏はこのように述べ、ほかのパフォーマンス上の懸念も挙げた。

　O3DはC++プログラミング言語で書かれており、コンピュータ上で高速に実行されるようコンパイルされている。O3Dを使うには、プログラマーはJavaScriptを書いてから、O3Dインターフェースを呼び出してさまざまな機能を実行する。

　WebGLを使うことは、O3Dが扱うタスクもJavaScriptで書くことを意味する。JavaScriptは大幅に速くなっているが、一般的には、コンパイル済みのソフトウェアと比べて、多くのプログラマーが速いと思うようなものではない。

　もう1つの問題は機能だ。O3Dを使ってソフトウェアを書いたことのある人にとって、そのインターフェースのうちいくつが利用可能になるのかはっきりしない。

　Chromeの機能説明には、「O3Dのもともとの機能すべてが、このような方法で（現実的に）実装可能だというわけではないが、目標は、サードパーティーとGoogleのO3D開発者がWebGLへ簡単に移行できる道筋をつけるのに十分な機能を実装することだ」と書かれている。

　後に、これに関与しているプログラマーは、「この点でわたしは大きく前進した。古いO3Dデモのいくつかは、デモコードに簡単な修正を加えることで、新しいクラスを使って正しく機能している」と付け加えている。

　現在、O3DのJavaScriptベース版は、Chrome 5とともに出荷される予定だが、最近になって一部の機能がChrome 6に先送りになっているので、このスケジュールは確定済みと考えるべきではない。