WPFに移行すべきか否か
WPF (Windows Presentation Foundation)は、2006年11月に.NET Framework 3.0に含まれてリリースされてから4年弱経過している。
リリース前に調査を行い幾つかの問題があり採用を見送った。
当時と現在では状況も.NETのバージョンも異なっているし、Windows 7のリリースやDirect2D、DirectWrite等のAPIも増えている。
ここで再度WPFの有効性について検証してみることにする。
ただし、Windows Vista（できればWindows 7以降）が対象で完全スクラッチのアプリケーション開発では全く異なった結果になるだろう。
また、.NET Framework 4.0に移行するかどうかは全く別問題である。
現状4.0に移行しない理由はほとんどないと判断している。
.NET 3.0でWPF移行を見送った理由
かなり大きい既存GUIアプリケーションをWPFに移行するかどうか検討という前提条件。
- 開発環境が異常に遅い（開発環境の操作性）
開発効率が受け入れ難いほど落ちる - 実行が遅い
操作の軽快感が重要なアプリの為。
非力なXP環境のユーザがまだ非常に多い。 - GUIコンポーネントの互換性がない
せめて自動移行できれば・・・。
外部コンポーネントのWPF版が無い。あっても買い直し。 - GUI系の処理が書き直しになる
そのコストは膨大。 - 標準コントロールがWinFormと対応付けできていない
対応するコントロールがなく、貧弱。 - デザイナとプログラマの分離思想はメリットが無いどころかデメリットしかない
私の周りでは残念ながら”デザイナ”という職種もしくは専任者は存在せず、UIレビューでアプリケーション全体との整合を確保している。
ソースが分かれることは、単に面倒になっただけ（”どちらにも持てる”は両方調べないといけなくなる事を意味する）
ディグレード等のリスクが増える。 - 多言語対応の方法が分からない
- 移行してもユーザビリティの向上が期待できず開発コストの低減も実証できない
- 色名に対する表示色が変わる
- 印刷系が大きく変わる
- Windows XP （SP2含む）でVistaと全く同様に動作する確証が得られない
少ないコストで整合できれば良いが、”制限つきで動作”等の不明確な情報しか得られなかった。
すべての要件を調査確認してはいません。
この辺りで調査を中断してWinFormの使用継続を決定したため、まだ致命的な問題はあるのかもしれません。
.NET 4.0のWPFはWinFormを凌駕しているか
前提となる2010年9月現在の状況
- Windows XPのシェアがまだまだ高い
一般的なシェアやPCの販売ではなく、顧客での稼働PCや最近の顧客導入PCのOS選択状況での話です。
Windows Vistaはほとんど存在せず、Windows 7も極々一部（たぶん1％もいかない） - 顧客でWDDM 1.1ドライバが動作しているPCは、ほとんどゼロ
- Windows 7のGDI/GDI+は遅い（スループットが低い）
- 同一PCにインストールされるアプリケーションが64Bit版に移行する理由から、64Bit OS対応のニーズが高まっている
- Visutal Studioは2010にバージョンアップしていてWPFベースで作成されている。
WPFの使用例として可能性を確認しやすい。
そのうえで、.NET 3.0の時のWPFの課題をクリアしているか検証してみる
- 開発環境が異常に遅い（開発環境の操作性）
開発用PCもアップグレードしている。Visual Studio 2010でWPFアプリケーション プロジェクトを作成してコントロールを配置。プロパティを操作してみると以前よりはましであるが、もたつきがある。落第点ではないが合格でもない。
コントロール数が増えていくと結構きつい。 - 実行が遅い
画面上の要素数が増えると遅くなってくる。
少なくともWinFormより速くなってくれれば移行の動機となる。 - GUIコンポーネントの互換性がない
状況は変わらず。 - GUI系の処理が書き直しになる
状況は変わらず。 - 標準コントロールがWinFormと対応付けできていない
少しコントロールが増えているようだが少ない。 - デザイナとプログラマの分離思想はメリットが無いどころかデメリットしかない
状況は変わらず。XAMLでできる事が増えている分むしろ悪化している。 - 多言語対応の方法が分からない
こちらも見つけられない。 - 移行してもユーザビリティの向上が期待できず開発コストの低減も実証できない
状況は変わらず。 - 色名に対する表示色が変わる
状況は変わらず。 - 印刷系が大きく変わる
状況は変わらず。WPFネイティブ対応のプリンタ・プロッタを顧客が導入している可能性、推進可能性が低い。 - Windows XP （SP2含む）でVistaと全く同様に動作する確証が得られない
Windows XPについてはSP2対応が廃止、SP3に移行している。また、Vista対応は限定的にしてWindows 7対応がメインになっているが、状況に大きな変化はない。
むしろ、Windows XPの2014年までの延命が確定的になり、Windows 7の新機能に対応する事による改善よりもXPとの整合維持にリソースを回す必要が確定的になった。
結果として現時点では、多大なコストをかけてWPFに移行しても費用回収の見込みも、顧客満足度の向上も見込めないのが分かる。
その他の要因
- Direct2Dついて
描画系をDirect2Dに変えるプロトタイプを作成してみたが、速度の向上はほとんど無い。
（WDDM1.1ドライバを使用しても。）
リソース管理が煩雑となり（GDI+と比較してであるが）、リークの危険性も増える。
リモートデスクトップでの速度向上も圧倒的ではなく、計測してみないとわからない。
実際早くなった感覚はない。 - DirectWriteについて
GDI+でのテキスト描画コードをDirectWriteに変更してみたが、特に向上した感覚はない。
印刷系（GDI+やHPGL、DXF、PDF）との整合を取っていく方が大変。 - Silverlight
現在のSilverlightは、対象アプリケーションの要件を満たす事が出来ない。
このため、SilverlightがWPFのサブセットとして構築されていることはメリットとならない。 - MonoがWPFには対応しない
万一であるが、Linux対応のニーズが高まった際にMono上で動作させることで開発コストを下げるという可能性を捨てる事になる。 - XPSドキュメントの普及
OfficeでPDFを直接吐けるようになり、XPSドキュメントの普及可能性が劇的に低下したと考えている。
XPSドキュメントが普及すれば、WPFに移行する牽引力の一つになったはず。 - インテル® AVX命令
Intelの新しい命令群はWindows 7 SP1からサポートされる。
これらが.NET Frameworkで使用されるのはあったとしてもまだ先の話になる。
Windows 8（仮）と.NET Framewok 5.0（仮）とか。
では、ずっとWinFormで行くのか？
いずれはWPFに移行する必要があるのだろう。
MicorosoftはWPFに投資しているし、WindowsのShellや描画APIもGPUを使用するDirect?系に注力している。Windows 7でGDI/GDI+にも並列実行の改善が施されたようであるが、実際にはスループットの低下によってアプリケーションの速度低下が発生してしまっている。
挙句、古いグラフィックス ドライバを使用するとGDIでもGPUによるアクセラレーションが得られるとか、大昔の混沌とした時代に戻ったようだ。
ただ、GDI/GDI+を使い続けるのはWindows 7の後継OS以降でどうなるか分からない。
ではWPFに今移行するとどうなるか。
XP、Vista、Windows 7とServer系、リモート系に対して自動テストが難しいGUI系の回帰テストをDirect？のバージョン毎に行うという修業が待っている。
この耐え難い（コスト的にもストレス的にも）苦行の先にあるものは・・・
結論：
WPFにはWindows XPと7との間にある溝を埋めることができない。
フレームワークに本来期待される機能を果たしていないことからも、現状WPFを採用することは困難で、それを乗り越えるほどの革新もメリットも見つけられない。
いつ移行するか？ それはWPFがフレームワークとして十分に動作するとき！
つまり、XPを無視できるときだろう。
それは、最短2014年。今から4年後。たぶん最新環境はWindows 8と.NET Framework 5.0になっていて、Vistaはサポート外とすることになり、今Windows XP PCをダウングレード等で購入した一部顧客への対応で済む事になる。
それまでは、64Bit版Windows対応をきっちり行い、.NET 4.0のTPL等で並列化を進めると同時にWPFの動向を見るのが最善と思う。
Category : WPF
|
|
Trackbacks [0]
コメント