windowフォームとWPFに関して教えて頂きたいです。

Question

WindowFormsとWPFのそれぞれの良い点と悪い点を皆さんにお聞きしたいです。
自分で調べた範囲では以下の内容くらいしかなかったのですが、
実際の現場レベルでの評価など、差し支えなければ教えて頂ければありがたいです。
※内容で認識違いあれば突っ込んでいただけるとさらにありがたいです。

○Forms
・良い点
→デザイナで使用できる部品の種類が豊富。
→作りやすい？

・悪い点
→公式が更新しなくなったのでバグが残ったまま。
→画像描画がラスタ形式なので複雑な事をするとパフォーマンス低下。
→デザイナ上で設置した部品のサイズ変更が容易ではない。
→dpiを意識しないと環境によって表示がおかしくなる。

○WPF
・良い点
→画像描画がベクタ形式なので複雑な事をしてもパフォーマンスが低下しない。
→公式がまだサポートしてる？
→デザイナ上で設置した部品のサイズ変更が容易。
→dpiを意識しなくてもOk。

・悪い点
→全体的にパフォーマンスが悪い？

以上です。

Answer 1

良い悪いの前にいくつか間違っている箇所があるので指摘させていただきます。
・WPFはベクタ画像をサポートはしていますが、従来通りラスタ画像を使えますし、ベクタ画像を使うのはそれほど一般的ではありません。（用途がかなり限定されます）
・「全体的にパフォーマンスが悪い？」これはどの部分を指していっているかによりますが、描画に関してはGPUサポートが入るので基本的にwindowsformよりリッチな画像や演出を扱うことができます。

どちらがいいとは一概に言えませんが、本格的なアプリを作るならWPF。簡単なツールで済ますならwindowsformと私は使い分けています。

Comments

[suzuki123]

＞良い悪いの前にいくつか間違っている箇所があるので指摘させていただきます。
　こういった指摘は大変有難いです。

＞全体的にパフォーマンスが悪い？」これはどの部分を指していっているか
　こちらに関しては、どこかのサイトでxamlを経由するうんぬんで遅い？みたいな事が記載されていたと思います。（読解力の問題で実際はそう記載されていないかもですが）
　で、ためしに簡単なプログラムを作成し、それぞれを検証してみたところ、そんなに違いはありませんでした。（起動が遅いというのも今の所意識するほどでもなかったです。）

[ishi9]

すいません、私の方で一点、勘違いというか明らかに誤解を招く表現がありました。
>ベクタ画像を使うのはそれほど一般的ではありません。
これはベクタ形式の画像ファイルを使うのが一般的ではないという意味で、
Shape等、よく使うものもあります。

Answer 2

WPFがFormsと違うのは、「XAML」を使うことです。
XAMLをかんたんに言うと、HTMLとXMLの中間みたいなものです。

だから、Webみたいにロジックとビューの分業ができるので、
複雑な動きも指定しやすいです。MS式Web風UIみたいな感じです。

それで、使い分けのイメージとしては、ビジネスがFormsで、ゲームがWPFです。
あるいは、四角い箱に文字を入れるのが中心ならForms、
アニメーション、3DCG、タッチパネルが中心ならWPF。

それから、WPFは描画のクセがあります。Formsとどっちが早いか
認識が食い違うのは、WPFの非同期描画（保持モード）のためです。

しかし、今のGPUが早いため、最適化する前提なら、
Formsより性能限界は高いはずです（代わりに難しくなりますが）。

Comments

[suzuki123]

＞それから、WPFは描画のクセがあります。Formsとどっちが早いか
認識が食い違うのは、WPFの非同期描画（保持モード）のためです。
　これに関しては、勉強中なのですが、「Dispatcher」の事を指しているという認識であっていますか？

＞それで、使い分けのイメージとしては、ビジネスがFormsで、ゲームがWPFです。
あるいは、四角い箱に文字を入れるのが中心ならForms、
アニメーション、3DCG、タッチパネルが中心ならWPF。
　両方の要素（画面自体はビジネスチックなのに、一部機能がゲームっぽい）が必要になった場合、両方の機能を使用するという選択は有りでしょうか？
　もし有りだった場合、WPFベースでやるべきかformsベースでやるべきかお勧めがあれば教えていただければ幸いです。（内容次第だと思いますが、どちらかベースだとテキストボックスか何かで不具合？があるという記載をどこかで見ましたので、こっちのほうがバグの影響少ないよとかでもかまいません。）

[LLman]

＞「Dispatcher」の事を指しているという認識
私の認識だと、それはイコールの関係ではなく、
非同期描画を制御する仕組みのひとつです。

＞両方の要素が必要になった場合、両方の機能を使用するという選択
WPFを半分しか使わなくても、学習コストは半分になりません。
その併用のバグとかを調べたり、途中で頭を切り換えるために、むしろ増えます。

また、描画基盤が違うので、パフォーマンスにオーバーヘッドも生じます。
だからむしろ、学習コストが高い割に、早くないという事態になりえます。

併用は可能ですが、二兎を追うより、どっちか一方が分かりやすいです。
途中までFormsでかんばり、限界を感じたらWPFへ移行するとか。

逆に、Web（HTML+CSS+JS）が分かる場合は、最初からWPFでいいかも。
それに、全体的なバグはWPFの方が少ないです。サポートされていますし。

ただ一方で現実には、一部には併用した方が便利な部分も存在するし、
MS的な理想は最初からUWPでしょうし、複雑な部分はあります。

[suzuki123]

＞また、描画基盤が違うので、パフォーマンスにオーバーヘッドも生じます
　この件は盲点でした。便利そうで手を付けた結果、後で痛い目を見るところでした。（実際それを経験することも大事だと思いますが）

＞併用は可能ですが、二兎を追うより、どっちか一方が分かりやすいです。
＞途中までFormsでかんばり、限界を感じたらWPFへ移行するとか。
　ここでの「移行」に関して、例えば「Formsで5割程作ったけど、何かしらの限界（保守性、不具合など）でWPFへ０から作り直し」という意味での「移行」でしょうか？
　それとも、「ここの機能はFormsで実装したら遅いけどWPFだと早いからこの機能だけWPFへ変更」という意味での「移行」でしょうか？

＞逆に、Web（HTML+CSS+JS）が分かる場合は、最初からWPFでいいかも。
＞それに、全体的なバグはWPFの方が少ないです。サポートされていますし。
　自分はWebに関してはあまり得意というわけでは無いですが、やはり不具合が少ないというのは重要な事なので、もう少し検討してみます。

[LLman]

＞ここでの「移行」に関して
両方半々ではなくて、Formsで十割作り、WPFの方が良いと思えば、
次はWPFで十割作る、という意味での完全「移行」です。

昔の商業アプリも、3Dゲームなどを除いて、Formsで作られていたわけですから、
「Formsだからできない」ということは、よほどでないと無いと思います。

Answer 3

レンダリングにGPUを使うWPFのほうが表示は軽い気がしますね。簡単な３Dも使えますし。
似て非なる物なので、一概には言えませんが、WindowsForm は敷居が低い気はします。

Comments

[suzuki123]

＞WindowsForm は敷居が低い気はします。
　WPFに比べると確かにそんな感じはしました。（おそらくXAMLのせい？）

＞レンダリングにGPUを使うWPFのほうが表示は軽い気がしますね。
　これに関しては、どれくらい軽いか試してみようと思います。