Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

6,928 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. Microsoftを16倍出し抜く C#+WPF開発手法 第2回(1~4倍までの道) 山本礼貴
  2. 2. 誰のためか 対象者  C#と.NET Frameworkに対する大まかな知識を持つ人  WPFに対する大まかな知識を持つ人  第1回目のスライドをご覧いただいた人には、より効果的な 動機  WPFのプログラムの動作が遅いという懸念や不満
  3. 3. 頂上までの道 WPFの根本的問 題を解決する (16倍~) WPF を制御する (4~16倍) WPFを効率的に使う (1~4倍) 誤った使い方をしないこと (~1倍)
  4. 4. アジェンダ 16倍っていかほど? 仮想化パネル自作という道 ちょっとしたデモ まとめと次回予告
  5. 5. 16倍っていかほど? 大変に思えますが、実のところはそうでもない。 大体の16倍の根拠について。
  6. 6. 大前提 画面に収まらない規模のデータを扱うときの話です。 画面に収まる程度ものが遅いというのは何か別の問題と考え ましょう。(例えば、第1回目で問題にしたようなこと)
  7. 7. 一般論で 考える 量的な面から物を減らしていくというアプローチは正しい。  データをグルーピングしたり絞り込んだりする。  遅延評価する。  表示を省略する。表示しないでいいUIを選択する。 (折りたたんだツリーとか)  ただし、これらは多くの場合一覧性に対するアンチかも。 データ形式に特化されたアプローチの良し悪し  再利用性が低いので、毎回毎回やる羽目になります。  とはいえ、速くなることは間違いない。 システマチックなアプローチは大切です。  再利用ができるから。  簡素なコードが速く動くから。  他のアプローチと相乗効果が働くから。
  8. 8. 高速化を 座標軸で 考える システマチックに考えてみましょう。 我々が認識できる軸は4つしかない  画面の平面(X軸、Y軸)  コントロールの前後関係(Z軸)  描画に要する時間(時間軸) だったら、1軸あたり2倍の速度にできたら、2の4乗・・・ すなわち16倍。いけそうな気がする。 そのうち4倍を勝ち取る、画面の平面への最適化。 それは仮想化パネルそのものじゃないか!
  9. 9. 本日のお題 水平方向の 高速化 (1~4倍) 仮想化パネルって何するの?  仮想化パネルとは、画面外にあるものに対して、速度に影響し そうな処理を省略するパネルの事です。  例)画面内に入る前のコントロールを生成しない  例)画面外にあるコントロールをパネルから取り外す  例)使用の終わったコントロールをリサイクルする  MicrosoftはVirtualizingStackPanelしか用意してくれていません。  この圧倒的な不足感は、自作するか、何かを買うしかなさそう です。  とりあえず、自作する路線にしましょう。  買ったものが遅かったとき理由がわかりません。  自分でメンテしているものなら大丈夫。
  10. 10. 仮想化パネル自作 という道 ひとまず簡単に作れる範囲から
  11. 11. 知っておくべ きこと ビジュアルツリーのことは多少知っておくと良い。 標準の仕様からどこまで離れることを許容しますか? 最小限、このくらいは変化します。  IsVisibleとか、VisualPanrentChangedのようなイベントが発生す るタイミングは変わります。  Loaded、Unloadedも変わります。  Childrenは「今表示されている子」のリストであり、所属して いる全ての子を表すようにならなくなります。  レイアウトパスの前に、画面外の要素を外したりする必要があ ります。  つまり、特定のイベント依存で処理をしてはいけません。 事前に読んでおくべきリファレンスコードはどこか  ひとまず、Panel.csとFrameworkElement.csかな。
  12. 12. 高速化のため にすること 仮想化はパネルの責務です。でも、コントロールが協力的な ら仮想化は高速です。 (専用のインターフェースくらいならあってもいいかなと思 える理由) まるで、すべてのコントロールが今までと同じように動かな ければいけないという考え方は捨てます。 (遅いものにいつまでもとらわれては速くなりません。) レイアウトパスを上手に活用して、適切なタイミングで画面 外のコントロールを低コスト化してやることです。
  13. 13. ビジュアルツリーの 居場所はこのあたり ビジュアルツ リーを知る イベント ユーザーコー ド バインディン グパス レイアウトパ ス 描画パス
  14. 14. 例) ボタンの ビジュアル ツリー Button ClassicBorderDecorator (ボタンのスタイル) ContentPresenter (ボタンの中身) StackPanel Image TextBlock <Button> <StackPanel> <Image Source=“~.bmp” /> <TextBlock> ボタン <TextBlock/> </StackPanel> </Button> XAMLとイコールではあり ませんが、構造は近しいも のがあります。
  15. 15. パネル側に 実装するもの 子を追加、削除するメソッド  Childrenとは別途管理します。 画面の表示範囲Viewportに応じてコントロールの着脱処理を 行います。
  16. 16. ちょっとしたデモ 速度差の体感用です。が、あまり速くなった気がしな かったらごめんなさい。それは、次回以降のネタなので す。
  17. 17. 違い 初期表示は数十倍は高速 マウスのあたり判定も数倍高速 スクロールはちょっと遅い?(←理由は後ほど) そんなことはいいから、ちょっとソースを見ましょうか。
  18. 18. たった これだけで 仮想化 (パネル) Children候補を蓄積しといて Viewportに入ったら着脱
  19. 19. たったこれだ けで(以下略) スッカスカです
  20. 20. 違反が あります 30分で書いたので、粗はごめんなさい。 実は1つ重大な違反してます。  ScrollChangedはレイアウトパス発のイベントです。そこで、 子の着脱をするということは、ユーザーコードのパス、バイ ンディングパスをやり直す可能性が生じます。 (第1回目であれほどダメだと言っていたのに) スクロールがさほど速くなっていなかったのはこれが理由で す。 仮想化しても思ったほど速くならんなーという人が悩むポイ ントでもあります。(重要)
  21. 21. まとめと 次回予告 まとめ  仮想化パネルは水平方向の速度を向上します。  ただし、標準とは異なる挙動をするようになるため、いくつか の禁止事項が生じます。  速さが最も際立つのは、生成時とヒットテスト  コントロールの着脱分、スクロールはちょっと遅くなります。 次回以降予告  コントロールのリサイクリングによって、省メモリと高速化を 同時に実現します。  Panelを継承するから発生する最大の問題について。  Zindex問題の解消方法。随一のトリッキーなパネル。
  22. 22. ご清聴ありがとう ございました。 http://proprogrammer.hatenadiary.jp/ こちらもご覧ください。

×