1

私は現在、WPF リッチ クライアント LOB アプリケーションのパフォーマンスの問題に関連する顧客の割り当てで働いています。

問題は、アプリケーションの実行が非常に遅い/遅いことです。特に、データ テーブルの処理 (スクロール、並べ替え、選択) は非常に遅く、アプリケーションが使用できなくなります。

いくつかのテキストボックス、コンボボックス、およびラベルを含む 1 つのタブが開かれ、アイドル状態 (ユーザーの入力待ち) になったときのシステム状態を分析しました。

これらは私の発見です：

  • すべてのレンダリングは GPU で計算されます
  • アニメーション、ビットマップ効果、透明度などのパフォーマンスの高い機能はありません。
  • タブがアイドル状態の場合 (フォーカスされたテキスト ボックス内でカーソルのみが点滅し、タブの残りの部分は静的で、データさえ含まれていません)、GPU は最大 90% 実行されます。
  • タブがフォーカスを失うたびに GPU が 0 に落ちる
  • GPU の割合は、ウィンドウ サイズに直接関係します。小さなウィンドウでは数パーセントに下がり、全画面表示ではほぼ 100% になります
  • WPF Perforator は、WPF が点滅カーソルだけでなく、タブ全体のダーティ領域を計算することを教えてくれます
  • WPF Perforator は、アイドル タブで 20/秒を超えるダーティ rect 更新レートを報告し、GPU 使用率に直接相関します

私の結論: 開発中に、システム全体のバックエンド駆動型アーキテクチャに WPF を適合させるために、多くのカスタム コード (レイアウト、イベント処理など) が導入されました。私の推測では、一部のカスタム コードが原因で、WPF の dirty-rect-mechanism が壊れています。これにより、描画アクティビティが過剰になり、GPU 使用率が非常に高くなります。これらの不必要な活動は、上記の問題につながります。

今、私は調査をどこから始めるべきかアドバイスを探しています。言い換えれば、開発者が WPF ダーティ rect 更新アルゴリズムを破るために犯す可能性のある典型的な間違いは何ですか。どんな入力でも大歓迎です。

これからもよろしくお願いします！

マヌエル

4

1 に答える 1

3

入力していただきありがとうございます。バックエンド主導であることを明確にしましょう。UI は非常に動的です。バックエンドからのメッセージは、UI の構造と表示されるデータを定義します。したがって、タブの構造用の xaml はなく、c# のみです。

その間、私は問題を解決することができました。Snoop を使用し、GPU の使用状況を監視しながら、すべての要素を 1 つずつ折りたたんでいきました。境界線の 1 つに非常に小さなピクセルシェーダー効果 (DropShadowEffect) があることがわかりました。エフェクトを削除するとすぐに、GPU は 80% から 1% に低下しました。WPF は、UI の小さな部分に正しいダーティな四角形を描画しました。問題は解決し、ケースはクローズされました。

興味深いと思われる点: 1. この小さな効果が GPU の使用に及ぼす多大な影響。2.dirty-rect 計算を壊すこと。3. これは BitmapEffect ではなく PixelshaderEffect だったので、Perforator で BitmapEffects を無効にしても明らかになりませんでした。

ありがとう！んん

于 2013-09-17T20:16:45.137 に答える