すべてのブラウザがWebGLを持つ中、グラフィックスAPIのバージジョン2.0はメジャーなアルファ版ブラウザ内に実験的に実装化され始めている。WebGL 2.0はOpenGLes 3.0.に基づくものである。理論上、機能性は同じであるが、望ましくないリミットやハードウェアや外部APIにやや予想外の互換性の問題をもたらすようなウェブに対してはサンドボックスで保護されている。

OpenGLes 3.0はレベル18以降、アンドロイドの一部となっている。私たちはiOS
8.0がこの動きに追従すると予想していたが、代わりに乱雑なGPUプログラムポータビリティに第3APIを追加したMetalを得ることとなった。
一方で、アップルはsafari iOS8ではWebGLをサポートすることを発表した。他に誰がwebGLを使っているだろうか？ソニーのプレイステーションストアではPS3のために下位互換性を保っている。次にグラフィックAPIポータビリティの標準となるのはnative
OpenGLes 3.0よりもむしろwebGL 2.0であろう。もし拡張機能によってサポートされているKronosのスタンダードにコードを限定すると、ベンダー固有のコード書くという問題からは解放されるかもしれない。しかし、パフォーマンス上の理由で、ほとんどの場合、ベンダー固有のコードが必要となり、それらコードはそれぞれにセグメンテーションされることが必要となる。例えば、webGLはウィンドウズ上でのthe
DirectXの機能の呼び込みをサポートするようになり、これによって、コード上のいくつかのセグメンテーションが必要となる。

GPUテクニックの本当のインパクトについて考えるポイントに立ってみると、GPUプログラミングとグラフィックテクニックはしばしばハードウェア認識外で実装されている。最適化は拡張機能に依存したものというよりも、データ設計に関連したアップデートである。よって、（恐らく、パーティクルエンジンを除いては）実際のWebGL上で計算されることができないwebGL 2.0において、誰も劇的に新しいビジュアル効果を見ることはない。しかしすべての過程は、例えばビデオゲームのような豊かで、広がりのある洗練されたスペースを与えるためのAPIのパフォーマンスを増進させるもののはずである。その他の特性はマルチサンプル用のRenderbufferのようなポストプロセッシングパス経由で画質を向上させるものとなる。

WebGL 2.0によって増幅されるある壮大なコンピュータービジュアルはパーティクルエンジンであり、また、クロスや流体シミュレーションのような拡張システムである。3Dテクスチャーは更に上級のパーティクルテクニックとシミュレーションにより、リアルタイム3Dデータバッキングや複数のインスタンス配列をワンコールでレンダリングするのを可能にするものである。

^{© Silicon Studio Corp., all rights
reserved.}