Starling は、Flash Player 11 の新しい 3D 描画機能 "Stage3D" 上に構築された、オープンソースの 2D 描画用 ActionScript フレームワークです。FreeBSD ライセンス下で配布されます。
現在バージョン 0.9 が公開されています。ダウンロードはこちらのリンクから。 （Starling Framework v0.9）
Stage3D は直接 GPU 機能を活用できるため、従来よりもずっと高速な描画を実現できます。すでに、様々な 3D フレームワークが Stage3D に対応しています。
（Alternativa3D とか Away3D とか Minko とか Flare3D とか Mixamo とか）
Stage3D は強力なのですが、実際に使おうと思ったら、アセンプラでシェーダープログラムを書くとか、何れかの 3D フレームワークの使い方を学ぶ、つまりまったく新しいプログラミングモデルを学習しなければならなかったりします。
これでは、単純に高速な 2D 描画が欲しいだけなんだけど！の人にはちょっとハードルが高すぎるかもしれません。
このままでは一部の人しか Stage3D を使うまい、という心配があったかどうかは不明ですが、Stage3D の複雑さを隠しつつ高速な 2D 描画を実現できるよう開発されたのが Starling です。Starling は、使い慣れた表示オブジェクト風の API を提供します。一方、裏では Stage3D を呼び出して高速な GPU 描画を実現します。
つまり、たまたまとっても運の良い人は、既存のプログラムの表示オブジェクトを Starling のクラスに置き換える程度で高速化できちゃうかもしれないわけです。また Starling は、ビットマップフォントやスプライトシートといった Flash Player には無い機能も提供します。 （パーティクル効果も github から拡張機能をダウンロードすると使えます）
実は Starling は iOS 用のフレームワークとして知られる Sparrow を Stage3D にポーティングしたものです。つまり、
- Starling はモバイルデバイス上での稼動が既にある程度実証済みである
- Starling で開発したアプリは、簡単に iOS のネイティブアプリにポーティングできる
ということです。もう使わない理由は無い感じ？もしてきます。
"表示リスト" は早くなる？
さて、Flash 使いであれば、「Starling は置いといて、今まで作ってきた表示リストのコンテンツは高速化されないの？」 という疑問を持ったのではないでしょうか。
その答えは、「現在の構造のままでは難しい」 あたりかと思います。どこら辺が難しいのか、今まで実際に行われた改善の具体的な例を挙げてみると、
1．wmode=gpu の場合
wmode=gpu は Flash Player 10 から導入された機能です。基本的なアイデアは、各表示オブジェクトのベクター描画は CPU で行い、その結果生成された個々のビットマップデータを GPU に転送して、最終的な画像の合成は GPU で行うというものです。この処理は "GPU 合成" とも呼ばれます。
一度描画した表示オブジェクトが再利用できる場合、CPU はそのオブジェクトの描画処理をスキップできる、GPU にキャッシュしておけば転送も不要、というのが高速化の根拠です。ただし頻繁に再描画されるオブジェクトをキャッシュしようとすると、逆にパフォーマンスが低下します。
GPU 合成は、結局あまり使われることはありませんでした。それは、Flash Player の描画プロセスを意識しながらこのモード専用の作り方をしないと高速化されない （使う側にとってハードルが高い） 上に、通常のコンテンツを wmode=gpu で実行すると、返って多くのケースで遅くなってしまっていた、ためです。
これでは有効なオプションとは考えにくい、ということで、Flash Player 10.3 からは wmode=gpu は無くなり、wmode=gpu が指定されている場合は wmode=direct にフォールバックするようになりました。
2．renderMode=gpu の場合
renderMode=gpu は、モバイルデバイス向けに AIR 2.6 に追加された機能です。上の "GPU 合成" とは異なり、ベクター描画も直接 GPU に対して行います。そのため、"GPU ベクター" と呼んで、GPU 合成と区別されます。
CPU と GPU 間の大量の描画データ転送が不要なため、GPU 合成よりもボトルネックが少なくなります。また GPU 合成と比べてクセが少ない （あまり特殊な書き方をしなくて良い） ため比較的使いやすく、実際に GPU ベクターモードを使って高速化されたコンテンツがいくつも公開されています。
しかし、表示リストの機能のうち （少なくない） いくつかは GPU ベクターの処理を低速にします。そして、ムービークリップの階層が深くなる程、レイヤーが多くなる程、この傾向は大きくなります。結果として renderMode=gpu を指定したことで遅くなるケースもでてきます。
このように "GPU ベクター" は "GPU 合成" よりは有効だが、表示リストの機能を GPU でエミュレートするコストは無視できない、ということが分かります。特にデバイスでは GPU 描画の効果が高いため （AIR 3 では更に最適化されているようです）、renderMode=gpu が無くなることはなさそうですが、 GPU ベクターの特徴には注意しながら使うのがよさそうです。
ここまでをまとめると、
- 表示リストは CPU 描画を前提に設計されたモデルで、そのまま GPU で描画しても必ずしも高速化されない （GPU ベクターのケース）
- Stage3D が登場した以上、表示リストにこだわらず GPU 向きのモデルでコンテンツを構築した方が良いパフォーマンスが得られる
- だからといって、特殊な構築方法を前提にしてしまうと広く使われない、もしくは誤った使い方による問題が起こり易い （GPU 合成のケース）
となります。
これで、なぜ Starling が登場したのか、なぜアドビが使用を推奨しているのかが見えてきたかと思います。開発者には見慣れた表示リストのプログラムに見え、ランタイムからは Stage3D のプログラムに見える方式が良さそうだ、という認識なのでしょう。
だからといって、もうアドビは表示リストをあきらめた、という話ではぜんぜん無いようです。これからも表示リストに対する最適化や機能追加は継続されるでしょう。グラフィック制作のしやすさでは、やっぱり従来の表示リストを使った方が上ですし。 （なので Starling は主にゲーム向けのフレームワークと位置づけられているのだと思います）
もし描画パフォーマンスで悩んでいるなら （デバイス環境ではまだダメですが） Starling に飛びついてみましょう。ちゃんとしたツールサポートとかは無いですが、それに見合ったパフォーマンスが十分に得られることと思います。 （たぶん）
長くなったので次回に続きます。
遂にFlashの2D描の高速化が本格化してきましたね。
Flashゲームの描画パフォーマンスの向上を突き詰める際に非常に大きな武器になりそうなので、Starling非常に注目してます。