Msを16倍出し抜くwpf開発2回目

1. Microsoftを16倍出し抜く
C#＋WPF開発手法
第2回（1~4倍までの道）
山本礼貴

2. 誰のためか
対象者
 C#と.NET Frameworkに対する大まかな知識を持つ人
 WPFに対する大まかな知識を持つ人
 第1回目のスライドをご覧いただいた人には、より効果的な
動機
 WPFのプログラムの動作が遅いという懸念や不満

3. 頂上までの道
WPFの根本的問
題を解決する
(16倍～)
WPF
を制御する
（4～16倍）
WPFを効率的に使う
（1～4倍）
誤った使い方をしないこと
（～1倍）

4. アジェンダ
16倍っていかほど？
仮想化パネル自作という道
ちょっとしたデモ
まとめと次回予告

5. 16倍っていかほど？
大変に思えますが、実のところはそうでもない。
大体の16倍の根拠について。

6. 大前提
画面に収まらない規模のデータを扱うときの話です。
画面に収まる程度ものが遅いというのは何か別の問題と考え
ましょう。（例えば、第1回目で問題にしたようなこと）

7. 一般論で
考える
量的な面から物を減らしていくというアプローチは正しい。
 データをグルーピングしたり絞り込んだりする。
 遅延評価する。
 表示を省略する。表示しないでいいUIを選択する。
（折りたたんだツリーとか）
 ただし、これらは多くの場合一覧性に対するアンチかも。
データ形式に特化されたアプローチの良し悪し
 再利用性が低いので、毎回毎回やる羽目になります。
 とはいえ、速くなることは間違いない。
システマチックなアプローチは大切です。
 再利用ができるから。
 簡素なコードが速く動くから。
 他のアプローチと相乗効果が働くから。

8. 高速化を
座標軸で
考える
システマチックに考えてみましょう。
我々が認識できる軸は４つしかない
 画面の平面（X軸、Y軸）
 コントロールの前後関係（Z軸）
 描画に要する時間（時間軸）
だったら、1軸あたり2倍の速度にできたら、2の4乗・・・
すなわち16倍。いけそうな気がする。
そのうち4倍を勝ち取る、画面の平面への最適化。
それは仮想化パネルそのものじゃないか！

9. 本日のお題
水平方向の
高速化
（1~4倍）
仮想化パネルって何するの？
 仮想化パネルとは、画面外にあるものに対して、速度に影響し
そうな処理を省略するパネルの事です。
 例）画面内に入る前のコントロールを生成しない
 例）画面外にあるコントロールをパネルから取り外す
 例）使用の終わったコントロールをリサイクルする
 MicrosoftはVirtualizingStackPanelしか用意してくれていません。
 この圧倒的な不足感は、自作するか、何かを買うしかなさそう
です。
 とりあえず、自作する路線にしましょう。
 買ったものが遅かったとき理由がわかりません。
 自分でメンテしているものなら大丈夫。

10. 仮想化パネル自作
という道
ひとまず簡単に作れる範囲から

11. 知っておくべ
きこと
ビジュアルツリーのことは多少知っておくと良い。
標準の仕様からどこまで離れることを許容しますか？
最小限、このくらいは変化します。
 IsVisibleとか、VisualPanrentChangedのようなイベントが発生す
るタイミングは変わります。
 Loaded、Unloadedも変わります。
 Childrenは「今表示されている子」のリストであり、所属して
いる全ての子を表すようにならなくなります。
 レイアウトパスの前に、画面外の要素を外したりする必要があ
ります。
 つまり、特定のイベント依存で処理をしてはいけません。
事前に読んでおくべきリファレンスコードはどこか
 ひとまず、Panel.csとFrameworkElement.csかな。

12. 高速化のため
にすること
仮想化はパネルの責務です。でも、コントロールが協力的な
ら仮想化は高速です。
（専用のインターフェースくらいならあってもいいかなと思
える理由）
まるで、すべてのコントロールが今までと同じように動かな
ければいけないという考え方は捨てます。
（遅いものにいつまでもとらわれては速くなりません。）
レイアウトパスを上手に活用して、適切なタイミングで画面
外のコントロールを低コスト化してやることです。

13. ビジュアルツリーの
居場所はこのあたり
ビジュアルツ
リーを知る
イベント
ユーザーコー
ド
バインディン
グパス
レイアウトパ
ス
描画パス

14. 例）
ボタンの
ビジュアル
ツリー
Button
ClassicBorderDecorator
（ボタンのスタイル）
ContentPresenter
（ボタンの中身）
StackPanel
Image TextBlock
<Button>
<StackPanel>
<Image Source=“~.bmp” />
<TextBlock>
ボタン
<TextBlock/>
</StackPanel>
</Button>
XAMLとイコールではあり
ませんが、構造は近しいも
のがあります。

15. パネル側に
実装するもの
子を追加、削除するメソッド
 Childrenとは別途管理します。
画面の表示範囲Viewportに応じてコントロールの着脱処理を
行います。

16. ちょっとしたデモ
速度差の体感用です。が、あまり速くなった気がしな
かったらごめんなさい。それは、次回以降のネタなので
す。

17. 違い
初期表示は数十倍は高速
マウスのあたり判定も数倍高速
スクロールはちょっと遅い？（←理由は後ほど）
そんなことはいいから、ちょっとソースを見ましょうか。

18. たった
これだけで
仮想化
（パネル）
Children候補を蓄積しといて
Viewportに入ったら着脱

19. たったこれだ
けで(以下略)
スッカスカです

20. 違反が
あります
30分で書いたので、粗はごめんなさい。
実は１つ重大な違反してます。
 ScrollChangedはレイアウトパス発のイベントです。そこで、
子の着脱をするということは、ユーザーコードのパス、バイ
ンディングパスをやり直す可能性が生じます。
（第1回目であれほどダメだと言っていたのに）
スクロールがさほど速くなっていなかったのはこれが理由で
す。
仮想化しても思ったほど速くならんなーという人が悩むポイ
ントでもあります。（重要）

21. まとめと
次回予告
まとめ
 仮想化パネルは水平方向の速度を向上します。
 ただし、標準とは異なる挙動をするようになるため、いくつか
の禁止事項が生じます。
 速さが最も際立つのは、生成時とヒットテスト
 コントロールの着脱分、スクロールはちょっと遅くなります。
次回以降予告
 コントロールのリサイクリングによって、省メモリと高速化を
同時に実現します。
 Panelを継承するから発生する最大の問題について。
 Zindex問題の解消方法。随一のトリッキーなパネル。

22. ご清聴ありがとう
ございました。
http://proprogrammer.hatenadiary.jp/
こちらもご覧ください。