Adobe の FlashPlayer のレンダリング アルゴリズムについて簡単に説明します

少し前に、Flash Player のレンダリング パフォーマンスが HTML 5 の数倍であることを紹介する CSDN の記事を目にしました。過去数年間にわたる Adob​​e の Flash Player に関する研究を思い出し、なぜそのようなパフォーマンスがあるのか​​を理論的に探ってみたいと思いました。 Adobe の Flash Player が従来のハードウェア アクセラレーション (非 GPU ソリューション) で批判されてきた理由について話しましょう
初期の頃、私は IC 設計会社で働いて、公式の Flash Player ハードウェア アクセラレーションを開発しました。ローエンド プラットフォーム (ハードウェア 3D アクセラレーション付き) いくつか 月末にはハードウェア レンダリング エンジンが完成しましたが、最終的な結果は非常に予想外でした。ハードウェア アクセラレーションに切り替えた後のパフォーマンスは、実際にはソフトウェア レンダリングよりも悪かったのです。その理由を説明するために、Adobe の Flash Player ソフトウェアから始めましょう。レンダリング アルゴリズムの原理から始めましょう
実際、FlashPlayer の 2D レンダリング エンジンは最も一般的なスキャン ライン アルゴリズム (スキャンライン アルゴリズム) を使用しており、簡単に言えば、仮想ディスプレイ デバイス (アンチエイリアシングを考慮して、仮想ディスプレイ。デバイスは、4 x 4 アンチエイリアシングなど、実際のディスプレイ デバイスよりも大きくなります。仮想ディスプレイ デバイスの垂直方向の長さは、実際のディスプレイ デバイスの 4 倍です。) ) 各走査線はベクトル グラフィックの各エッジ (エッジ) との交点を計算し、走査線が 1 つずつ計算された後、異なる塗りつぶしルールに従ってそれを塗りつぶします。上から下まで、仮想ディスプレイ デバイス内で完全なグラフィックが完成します。次に、スーパーサンプリング アルゴリズムに従って、仮想ディスプレイ デバイス上のグラフィックが実際のディスプレイ デバイスに出力され、エイリアスのない完全なグラフィックが得られます。実際の表示デバイス上で上記の動作を一定の割合で繰り返し、連続したアニメーションを取得できます。そして、FlashPlayer がストリーミング swf ファイルを解析し、指定された速度で画面を更新してアニメーションの再生を完了します。簡単な結論:
l ベクトル演算は膨大な計算です。これは、FlashPlayer がほとんどのプラットフォームでパフォーマンス上の問題を抱えている理由でもあります。非常に残念ですが、現在のリアルタイム 2D ベクトル グラフィックス再生ソフトウェアには FlashPlayer しかないようなので、これを行う方法はありません。これはスケープゴートのせいです
l 高解像度グラフィックスの表示パフォーマンスが低品質グラフィックスの表示パフォーマンスよりもはるかに悪いのはなぜですか?走査線による交点の計算は低画質の 4 倍です
(2D ベクトル グラフィックスの表示については、以前のリソースを参照してください: http://download.csdn.net/source/5773340)
実際の 2D ベクトル エンジンではキャップと結合を考慮すると、実際には非常に単純なポリラインやベジェ曲線でも多くの曲線で構成されます (グラフのポリラインの 2 つの端点 ---- キャップ):

このようにします。 Adobe FlashPlayer と競合できるリアルタイム 2D ベクトル表示プログラムがほとんどない理由は理解できます。これは少し矛盾していませんか。なぜ Adob​​e の FlashPlayer が優れているのでしょうか。上記は 2D ベクトル グラフィックス表示の原理の説明にすぎません。OpenVG (gingkoVG) や agg などの他の 2D ベクトル表示エンジンも、比較的一般的な 2D ベクトル表示エンジンである Adob​​e の FlashPlayer とまったく同じ原理を使用しています。独自の特別な定義については、FlashPlayer (swf_file_format_spec_v10) に関する Adob​​e の公式技術文書を注意深く読んでください。すぐに 2 つの非常に興味深い指示が見つかりました:
l FlashPlayer は 2 次ベジェ曲線 (2 次ベジェ) のみをサポートし、同様の PostScript および 3 次ベジェ曲線はサポートしません。 OpenVG などの従来の 2D ベクトル エンジンで使用されるベジェ曲線 (Cubic Bezier)


2 次ベジェ曲線と比較すると、交差を計算する際に 1 つの 3 次ベジェ曲線によって追加される計算量はそれほど多くないようです。大: さらにいくつかの乗算演算があります。ただし、ほとんどの CPU システムでは、乗算と除算にかかる時間は加算や減算よりも長くなります。特に演算量が非常に多い場合、累積差はさらに大きくなります。 ;
l Adob​​eの公式サイトには、FlashPlayerがダッシュ（Dash）をサポートしていないことがファイルに明記されています


なぜDashをサポートしないのですか？実際、ベクトル グラフィックス表示では、曲線と走査線の交点の計算に加えて、曲線の長さを計算することが最も難しいことです。Dash の表示は曲線の長さの計算に依存する必要があります。事前に; gingkoVG を実装する場合、Dash 関数のカーブは含まれていません。Dash を使用した場合の表示パフォーマンスが 4 倍であることがわかります。いいえ、しかし、上記の制約があっても、その表示パフォーマンスは数回「改善」されています。 Adobe の FlashPlayer では、他のいくつかの最適化アルゴリズムがレンダリングに使用されます。もちろん、これらの最適化アルゴリズムは、一般的な最適化手法としてほとんどの 2D ベクトル エンジンでも使用されます。アルゴリズム レベルで汎用性を考慮する必要があるため、ほとんどの 2D ベクトル エンジンが 3 次のベジェ曲線、一点鎖線、さらには円弧 (OpenVG) をサポートしているのは残念ですが、これらがオープンである理由を理解するのは難しくありません。標準の 2D レンダリング エンジン (gnash は agg を使用するなど) を使用するソース FlashPlayer は、Adobe の FlashPlayer の実行パフォーマンスと比較できません。これは、FlashPlayer の 2D レンダリング エンジンが Flash のリアルタイム ニーズに合わせてカスタマイズされているためです。もちろん、これらに加えて、Adobe の Flash Player にはプログラムの最適化に関する多くの優れた機能がありますが、ここでは説明しません。この問題はここで終わるように思えますが、FlashPlayer を徹底的に調査した結果、いくつかの深刻な問題が判明しました。また、広く批判されてきた Adob​​e の FlashPlayer のハードウェア アクセラレーション パフォーマンスの低下の理由も明らかになりました。特別な GPU のハードウェア アクセラレーションについては、この問題を説明するために標準のハードウェア アクセラレーション方法 (OpenGL ES/OpenVG) のみを考慮します。Adobe の FlashPlayer が誕生したとき、ユニバーサル 2D ベクトル表示標準 (OpenVG など) はありませんでした。 2D ベクトル グラフィックス ディスプレイは、10 年以上の開発と最適化を経て完成度に達しました。これは、そのレンダリング エンジンが以前から改善されていない理由の説明にもなります。 FlashPlayer 4 から FlashPlayer 8 へ。このような大きな変更は、Adobe FlashPlayer ソフトウェアのレンダリング パフォーマンスがローエンドのハードウェア アクセラレーションを使用するよりも優れている理由も説明できます。ただし、成功は失敗でもあり、完璧すぎる標準とアルゴリズムが標準ハードウェアの使用を妨げます。おそらく (特別な GPU のハードウェア アクセラレーション、その柔軟性は考慮されていないため)、引き続き Adob​​e の公式ドキュメントを注意深く研究し、FlashPlayer が充填法に関して従来の 2D ベクトル エンジンとは異なることに気づきました。 (OpenVG/gingkoVG など) には、偶数-奇数塗りつぶしルール (偶数-奇数塗りつぶしルール) と非ゼロ塗りつぶしルール (Non-zero 塗りつぶしルール) の 2 つの塗りつぶしルールがあり、Adobe の FlashPlayer ではエッジ塗りつぶしルール (Edge-edge ルール) が追加されます。塗りつぶしルール)、ほとんどの 2D ベクトル エンジンは各シェイプ/オブジェクトに対して 1 つの着色方法 (RColor) を使用します。エッジ-エッジ塗りつぶしルールでは、エッジは左と右に応じて 2 つの異なる着色方法 (color1/color2) を持つことができます。もちろん、Adobe がこれを行う理由は、ソフトウェア レンダリングの柔軟性を高めるためです。たとえば、図に示すように、2 つの Shape が交差する場合、交差する部分に異なる色付け方法が許可されます。標準のグラフィックス アクセラレーション エンジン (OpenVG/OpenGL) を使用すると、混乱が生じます。つまり、シェイプに対してさまざまなシェーディング方法が使用される可能性があり、これはほとんどの 2D ベクトル エンジンに反するように見えますが、エッジの塗りつぶしルールは次のように考えることができます。は、奇数と偶数の 2 つの異なる塗りつぶしルールですが、各エッジの塗りつぶしルールがいつでも変更される可能性があることを考慮すると、単一の色を持つ Shape を再確認することは、特に曲線で構成される Shape の場合、それほど簡単ではありません。ただし、この問題は 2D ベクトル グラフィックスのレンダリングに比べればそれほど厄介ではありませんが、Adobe FlashPlayer が今日のほとんどの従来の 2D ベクトル エンジンに対して「フレンドリー」ではないようであることがわかります。----- プログラマは中間層を慎重に作成する必要があります。これらの問題を解決してください。これは Adob​​e のせいではありません。FlashPlayer が誕生したとき、これらの 2D ベクトル表示標準 (OpenVG) はまだ登場していませんでした。Adobe の FlashPlayer がオープン ソース プログラムではないのはただ残念です (Adobe FlashPlayer の AVM2 はオープン ソースになっています)。 ) したがって、公式の FlashPlayer を使用しない限り、Adobe がこれを行うまで辛抱強く待つ必要があります
(私たちは OpenVG の FlashPlayer を使用しています)