たくさんのコントロールでウィンドウのサイズを変更するときのWPFパフォーマンスの問題

Question

私は、約5つのテンプレート（パス、シャドーエフェクトなど）を使用する約200個のコントロール（ボタンから派生したもの）を含む豪華なイメージを含むWPFウィンドウを持っています。 ）。合意した、それは描画するための重いウィンドウです。私はそれで生きることができます。

私の問題は、ウィンドウのサイズ変更によるものです。最大化/復元には約1〜2秒かかりますが、左下隅を手動でドラッグすると、システムは約5〜10秒間ハングします。この遅延では、ウィンドウには黒色の&が表示され、最後の結果が表示されるまで部分的な残量が含まれます。それは素人に見え、その、私は一緒に暮らすことはできません。

リモート接続：リモートアカウントを使用すると、ウィンドウのサイズ変更には常に1〜2秒かかりますが、ウィンドウの境界線をドラッグしている間は「中間」ステージが描画されません。その結果は、私が期待しているように気が狂っています。

私の結論は次のとおりです。の間に再描画され、ボトルネックです。

これは避けられない問題です。サイズ変更が完了するまで、どのようにしてウィンドウを再描画できないのですか？任意のアイデアを事前に

おかげで...

Answer 1

@Seb：私は、WPFが 時間

で2-3のコントロールを超えて に行くのインターフェイスのために設計されていないと思うし始めています

Visual Studio 2010とExpression Blendは良い反例でなければなりません。 Visual Studioが時々フリーズしても、ボトルネックはWPFレンダリングには間違いありません。

@Seb：避けられない質問はこれです：サイズ変更が終了するまで は、私は窓 を再描画防ぐことができますか？

サイズ変更/最大化を行う前に、ウィンドウのコンテンツ表示をVisibility.Collapsedに設定し、その後に表示するだけです。あなたは間違った質問をしたと思いますが。ここに正しいものがあります

私のコントロールは非常に速く測定/整列させる方法を教えてください。

そして、あなたのコードを見てください。たぶん、測定/配置アルゴリズムで依存プロパティを集中的に使用していますか？または、間違ったパネルを選択した可能性があります（たとえば、グリッドがCanvasよりも遅いなど）。それとも...私はここで推測を止める:)。

ちなみに、プロファイラの下でアプリを起動し、その場所を想定するのではなく、ボトルネックを証明する方が良いです。 Eqatec Profilerをチェックしてください。それは無料ですが強力です。 VS 2010は素晴らしいプロファイリング機能を提供しますが、それは無料ではありません。そして、WPF Performance Suiteにチェックしてください。

これが役に立ちます。

Answer 2

私はこれがどのように動作するか教えてください...あなたのルートビジュアルアイテムが、縦横に伸びて、ウィンドウの高さ/幅を自動で埋めると仮定しています。自動高さ/幅を取り除く。アプリ起動時に、ルート要素の寸法を設定します。 FrameworkElementsにはsize changed eventがあります。あなたのApplication.Current.MainWindowにこれを登録してください（おそらくタイプミスかもしれません。このイベントが発生するたびに、小さな間隔でタイマーを開始します。タイマーの実行中に別のサイズを取得した場合は、それを無視してタイマーをリセットしてください。タイマーが起動すると、ユーザーは望みの新しいサイズを知り、（少なくとも短期間は）ウィンドウのサイズ変更を停止しました。

希望に役立ちます！

Answer 3

Ragepotato's answerから

とインタフェースは限り、あなたはあなたのオブジェクトが動的に再配置する自分自身を持っていないとして、しばらくのリサイズどのように見えるかをざっと見する必要についてコメント（のようにWrap Panel） - あなたが取ることができますウィンドウの内容のスクリーンショットとあなたのフレームをそれで埋める。
高さと幅の両方を伸ばすように設定すると、特定のサイズのアイデア（やや曖昧）が得られます。サイズ変更中はライブではありませんが、おそらく問題ではない数秒間です。