WPFレンダリングシステムに深く浸る

「なぜWPFはすべての生き物よりも生き生きしているのですか？」および「7年間のWPF：何が変わったのか？」というエントリについて議論することで、この記事を翻訳するように促されました。

最初はこの記事を公開したくありませんでした。 それは失礼なように思えた-死者についてうまく話すか、何も言わないでください。 しかし、私が本当に感謝している意見を持つ人々とのいくつかの会話は、私の心を変えました。 Microsoftプラットフォームに多大な労力を費やした開発者は、その作業の内部機能に注意する必要があります。そうすることで、行き詰まりに陥った場合、何が起こったのかを理解し、プラットフォーム開発者の希望をより正確に定式化できます。 私はWPFとSilverlightを優れたテクノロジーだと考えていますが、...過去数か月にわたって私のTwitterをフォローしている場合、いくつかの発言はWPFとSilverlightのパフォーマンスに対する根拠のない攻撃のように思えるかもしれません。 なぜこれを書いたのですか？ 結局のところ、私は長年にわたって何千時間も自分の時間を費やし、プラットフォームの促進、図書館の開発、コミュニティのメンバーの支援などをしました。 個人的に個人的に興味があります。 プラットフォームを改善してほしい。



パフォーマンス、生産性、生産性

中毒性のある消費者志向のユーザーインターフェイスを設計する場合、パフォーマンスが最も重要です。 それがなければ、他のすべては意味がありません。 インターフェースが遅れたため、インターフェースを何回単純化する必要がありましたか？ 既存のテクノロジーでは実装できないため、「新しい革新的なユーザーインターフェイスモデル」を何回思いついたのですか。 2.4 GHzの周波数のクアッドコアプロセッサが適切に動作する必要があると顧客に何回言っていますか？ クライアントは、WPFとSliverlightでiPadアプリケーションと同じ滑らかなインターフェイスを取得できない理由を繰り返し尋ねてきました。4倍強力なPCを使用している場合でもです。 これらのテクノロジーはビジネスアプリケーションに適している場合がありますが、次世代のユーザーアプリケーションには明らかに適していません。

ただし、WPFはハードウェアアクセラレーションを使用します。 なぜあなたはそれを効果がないと思いますか？

WPFは実際にハードウェアアクセラレーションを使用しており、内部実装のいくつかの側面は非常にうまく行われています。 残念ながら、GPUの使用率は実際よりもはるかに低くなっています。 WPFレンダリングシステムは非常に強力な力を使用します。 この声明を以下に説明したいと思います。

WPFレンダリングユニットパスの分析

パフォーマンス分析のために、WPF内で実際に何が起こっているのかを理解する必要があります。 このために、DirectX SDKに同梱されているDirect3DプロファイラーであるPIXを使用しました。 PIXはD3Dアプリケーションを起動し、すべてのDirect3D呼び出しにいくつかのインターセプターを挿入して、それらを分析および監視します。

左から右に2つの楕円を表示する単純なWPFアプリケーションを作成しました。 両方の楕円は同じ色（＃55F4F4F5）で、黒い輪郭をしています。



そして、WPFはこれをどのようにレンダリングしますか？

まず、WPFは再描画しようとしているダーティエリアをクリーンアップします（＃ff000000）。 GPUパイプラインの最終的なマージステージに送信されるピクセル数を減らすには、ダーティエリアが必要です。 これにより、再テッセレーションが必要なジオメトリの量が減ると仮定することもできます。これについては後で詳しく説明します。 汚れた部分をきれいにすると、フレームは次のようになります



その後、WPFは不可解なことを行います。 まず、頂点バッファーをいっぱいにしてから、汚れた領域に長方形のようなものを描画します。 フレームは次のようになります（エキサイティングですよね？）：



その後、CPU上の楕円をテッセレーションします。 既にご存知かもしれませんが、テッセレーションは、100x100の楕円のジオメトリを一連の三角形に変換することです。 これは次の理由で行われます：1）三角形はGPUの自然なレンダリングユニットです2）楕円テッセレーションは数百の三角形のみをもたらすことができ、CPUによるアンチエイリアシングで10,000ピクセルをラスタライズするよりもはるかに高速です（Silverlightが行います）。 以下のスクリーンショットは、テッセレーションがどのように見えるかを示しています。 3Dグラフィックに精通している読者は、これらが三角形のストライプであることに気付くかもしれません。 テッセレーションでは、楕円が不完全に見えることに注意してください。 次のステップとして、WPFはテッセレーションを取得して頂点GPUバッファーにロードし、XAMLで構成された「ブラシ」を使用するように構成されたピクセルシェーダーを使用して別の描画呼び出しを行います。



楕円の不完全性に注意したことを覚えていますか？ 本当にそうです。 WPFは、Direct3Dプログラマーが「ラインリスト」として知っているものを生成します。 GPUは、三角形だけでなく線も認識します。 WPFはこれらの線で頂点バッファを埋め、何を推測しますか？ 正確に、別の描画呼び出しを行いますか？ 行のセットは次のようになります。



これで、WPFは楕円の描画を完了しました。 いや！ サーキットを忘れてしまいました！ パスは行のコレクションでもあります。 また、頂点バッファにも送信され、別の描画呼び出しが行われます。 アウトラインは次のようになります



この時点で、楕円が1つ描画されているため、フレームは次のようになります。



シーン内の楕円ごとに手順全体を繰り返す必要があります。 私たちの場合、2回です。

わかりません。 これがパフォーマンスに悪いのはなぜですか？

最初に気付くのは、1つの楕円をレンダリングするために、3つの描画呼び出しと頂点バッファーへの2つの呼び出しが必要だったことです。 このアプローチの非効率性を説明するには、GPUの動作について少し話さなければなりません。 まず第一に、最新のGPUは非常に高速で、CPUと非同期に動作します。 ただし、一部の操作では、ユーザーモードからカーネルモードへの移行にコストのかかる切り替えが発生します。 頂点バッファを埋めるときは、ブロックする必要があります。 この時点でGPUがバッファを使用している場合、これによりGPUがCPUと強制的に同期され、パフォーマンスが劇的に低下します。 D3DUSAGE_WRITEONLYで頂点バッファーが作成されます| D3DUSAGE_DYNAMIC、しかしそれがブロックされるとき（これはしばしば起こる）、D3DLOCK_DISCARDは使用されない。 これにより、バッファーがGPUによって既に使用されている場合、GPUで速度の低下（GPUとCPUの同期）が発生する可能性があります。 多数の描画呼び出しの場合、カーネルモードへの移行が多く発生し、ドライバーに大きな負荷がかかる可能性が高くなります。 パフォーマンスを改善するには、できるだけ多くの作業をGPUに送信する必要があります。そうしないと、CPUがビジーになり、GPUがアイドル状態になります。 この例では、1つのフレームについてのみ話していたことを忘れないでください。 典型的なWPFインターフェースは、毎秒60フレームを出力しようとします！ レンダリングストリームがプロセッサを非常に激しくロードしている理由を見つけようとしたことがある場合、ほとんどのロードはGPUドライバからのものであることがわかります。

そして、キャッシュされたコンポジションはどうですか？ 生産性が向上します！

間違いなく、増加します。 キャッシュビルドまたはBitmapCacheは、オブジェクトをGPUテクスチャにキャッシュします。 これは、CPUのサイズを変更する必要がなく、GPUを再ラスタライズする必要がないことを意味します。 1つのレンダーパスを実行する場合、WPFはビデオメモリのテクスチャを使用するだけで、パフォーマンスが向上します。 BitmapCacheの楕円は次のとおりです。



しかし、この場合もWPFには暗い側面があります。 BitmapCacheごとに、個別の描画呼び出しを行います。 私はうそをつきません。時には、単一のオブジェクト（ビジュアル）をレンダリングするために描画呼び出しを行う必要がある場合があります。 何でも起こります。 しかし、アニメーション化されたBitmapCached楕円が300個ある<Canvas />があるシナリオを想像してみましょう。 高度なシステムでは、300のテクスチャをレンダリングする必要があり、それらはすべてz順であることが理解されます。 その後、彼女は最大サイズのパッケージを収集します。覚えている限り、DX9は一度に最大16の入力要素（サンプラー入力）を使用できます。 この場合、300の代わりに16の描画呼び出しが行われ、CPUの負荷が大幅に削減されます。 1秒あたり60フレームの観点から、負荷を1秒あたり18,000の描画呼び出しから1125に減らします。Direct3D 10では、入力要素の数がはるかに多くなります。

さて、私はこの場所を読みました。 WPFがピクセルシェーダーを使用する方法を教えてください！

WPFには、拡張可能なピクセルシェーダーAPIといくつかの組み込み効果があります。 これにより、開発者はユーザーインターフェイスに真にユニークな効果を追加できます。 シェーダーを既存のテクスチャにフィットさせようとすると、Direct 3Dは通常、中間のレンダーターゲットを使用します...結局のところ、書き込み元のテクスチャをサンプルとして使用することはできません！ WPFもこれを行いますが、残念ながら、フレームごとに完全に新しいテクスチャを作成し、最後に破棄します。 GPUリソ​​ースの作成と破棄は、各フレームを処理するときにできる最も遅いことの1つです。 通常、同じ量のシステムメモリを割り当てても、これは行いません。 これらの中間面を再利用することにより、生産性の大幅な向上を達成できます。 ハードウェアアクセラレーションシェーダーがCPUに顕著な負荷をかける理由を疑問に思ったことがあれば、答えはわかりました。

しかし、それがGPUでベクターグラフィックスをレンダリングする必要があるのでしょうか？

マイクロソフトはこれらの問題を修正するために多くの努力をしましたが、残念ながらこれはWPFではなくDirect 2Dで行われました。 Direct2Dによってレンダリングされた9つの楕円のこのグループを見てください。



パスを持つ単一の楕円をレンダリングするために必要なWPF呼び出しの数を覚えていますか？ 頂点バッファーロックはどうですか？ Direct2Dは、これを1回の呼び出しで行います。 テセレーションは次のようになります



Direct 2Dは、可能な限り一度に描画を試み、GPU使用率を最大化し、CPU負荷を最小化します。 このページの最後にある Insights：Direct2D Renderingを読んでください。MarkLawrenceがDirect 2Dの内部詳細の多くを説明しています。 Direct 2Dのすべての速度にもかかわらず、2番目のバージョンではさらに多くの領域が改善されることに気付くかもしれません。 Direct 2Dのバージョン2は、DX11テッセレーションハードウェアアクセラレーションを使用する可能性があります。

Direct 2D APIを見ると、コードの大部分がWPFから取得されたと想定できます。 Michael Wallentがこの技術に基づいたGDI代替品の開発について語っているこの古いAvalonビデオをチェックしてください。 非常によく似た幾何学的なAPIと用語を持っています。 内部は似ていますが、非常に最適化されており、モダンです。

Silverlightはどうですか？

Silverlightを実行できますが、それは冗長です。 Silverlightのレンダリングパフォーマンスも低いですが、理由は異なります。 CPUを描画するために使用します（覚えている限りでは、それらは部分的にアセンブラーで記述されています）が、CPUはGPUの少なくとも10〜30倍遅いです。 これにより、ユーザーインターフェイスのレンダリングの処理能力が大幅に低下し、アプリケーションのロジックの処理能力がさらに低下します。 ハードウェアアクセラレーションの開発は非常に不十分で、WPFのキャッシュ構造をほぼ正確に繰り返し、同様の動作をし、BitmapCache（BitmapCachedビジュアル）を使用して各オブジェクトの描画呼び出しを行います。

では、今何をしますか？

この質問は、WPFおよびSilverlightで問題が発生したクライアントからよく聞かれます。 残念ながら、明確な答えはありません。 特定のニーズに合わせて独自のフレームワークを作成できる人。 ニッチにはWPFとSLに代わるものがないため、残りは条件に合わせる必要があります。 クライアントが単にビジネスアプリケーションを開発するだけであれば、スピードに関する問題はそれほど多くなく、プログラマの生産性を享受するだけです。 本当に興味深いインターフェース（つまり、コンシューマーアプリやキオスクアプリ）を構築したい人には、本当の問題があります。

翻訳の開始後すでに、計画されたパフォーマンスの最適化とWPF 4.6でのDX10-11の使用に関するニュースが掲載されました。 ニュースの記事に記載されている問題が解決されるかどうかは完全には明らかではありません。


ソース記事： WPFレンダリングシステムの重要な詳細