C#+WPFチューニング戦記

C#とWPFで高速なコードと最適なシステムを書くためにやってきたいろいろな事を書いてみます。.NET Frameworkのソースコードを読み解きましょう。なお、ここに書かれているのは個人の見解であって何らかの団体や企業の見解を代表するものではありません。

Msを16倍出し抜くC#+WPFの3回目(その前に)

スライドがどうも整ってないのでまだ公には出してないのですが。

今までくどくどと挙げてきたWPFボトルネックを全部避けてみるだけで、実際どの位速いパネルが生まれるのかというあたりをデモしました。

その時にちょっとおまけ話としてイベントの発射地点についてのまとめをしてみました。

MVVMが浸透した関係もあって、画面内のコントロールの使い方を誤る機会というものも多少減ったとは思うのです。
しかし、ScrollChangedとかSizeChangedとかのイベントの出所がどこのパスなのか、MicrosoftMSDNに正確に記載すべきじゃないかと思うのです。

上記2イベントはレイアウトパスでサイズ等々計算が終わったところで発射されます。
このイベントを受けてしまって、ついコントロールの描画にかかわる何かを書き換えてしまうと、バインディングパスやレイアウトパスはやり直しになる可能性があります。
いつになったら描画パスに移行できるのやら。

InvalidateVisualとかInvalidate系のメソッドの使用を諌めるよりもよほどこちらを気を付けるようにアナウンスしていただきたいと願ってやみません。
もちろん、上記メソッドもレイアウトパスをやり直させる効果があります。しかし、バインディングパスまでやり直しになる危険はありません。

本当に恐れるべきは、イベントの発射地点がどのパスにあるかということです。

そのあたりも、ぜひリファレンスコードを読んでみていただきたいと思います。

イベントの名前をここの検索ボックスで入力するだけです。
Reference Source