コメント一覧 (19)

1. • 1. mss
   • 2017/04/14 08:56
   • コメント失礼します。
     
     Win32人気ですね、確か以sourcetreeがWPFでUI作り変えてたような気がします。今もWPFかちょっとわかりませんが、、、
2. • 2. [管理人]
   • 2017/04/14 19:16
   • コメントありがとうございます
     
     見てみると ウィンドウを透明化できないところや メニューバーへフォーカスしたときの色が WPF のようです
     
     sourcetree が入ってる PC には inspect が入ってなかったので 100% と言い切れませんがたぶん WPF だと思います
     
     やっぱり WPF で作られたものは他の Win32/WinForms に比べてちょっと違う感がありますね
3. • 3. 通りすがりのプログラマーX
   • 2017/09/03 17:51
   • WPFは一般ユーザーが触れるアプリではほとんど使われていないと思いますが、企業で使われる業務用途のデスクトップアプリ開発で採用される事例はあります。WPFが使われない理由としては、既存のWin32/WinFormsのコード資産が膨大でWPFに移行できないことのほかに、QtなどのクロスプラットフォームなUIフレームワーク（たいてい内部でGDIやOpenGLなどを使って独自描画しています）を使っている場合はわざわざWPFで作り直すメリットがない、ということが挙げられると思います。
     Visual Studioは2010でWPFを導入しましたが、内部はWPF+WinForms+Win32の合わせ技ですね。WinForms/Win32用のUIデザイナーなどはWinForms/Win32で作られた資産が使われ続けています。C/C++のライブラリやコンパイラー、デバッガーまわりなど、ネイティブコードで書かれたものも依然として使われています。
4. • 4. ななしさん
   • 2017/09/12 12:43
   • ここでいっているWin32とは.NETで作られた物も含まれているのでしょうか？
5. • 5. [管理人]
   • 2017/09/20 20:56
   • なるほど
     そうなんですね
     
     詳しい解説ありがとうございます
     
6. • 6. [管理人]
   • 2017/09/20 20:59
   • > ここでいっているWin32とは.NETで作られた物も含まれているのでしょうか？
     
     .NET framework (Windows Forms と WPF) はそれぞれの名前が表示されているので Win32 と表示されているものは .NET を使わないネイティブなものかと思います
7. • 7. 4
   • 2017/09/25 11:23
   • >>6
     なるほど。私がよく使用しているアプリケーションもほとんどがWin32でした。
     時代は完全に.NETかと思ってましたが、実情はまだまだなんですね。
8. • 8. C#er
   • 2017/10/06 13:51
   • 日本においては「人」の問題の方が大きいと感じますね～。
     既存のものがあると
     ・そのまま使う
     ・あるなら簡単に作り替えてよ
     とかとか。。。
     
     「技術的負債は踏み倒す！」思想です。
9. • 9. [管理人]
   • 2017/10/15 13:56
   • C#er さん
     
     それすごくわかります
     
10. • 10. のん
    • 2017/11/28 10:38
    • WPFが遅いのはリッチなUIの描画に時間がかかっているだけで、
      Win32でも同じデザインのUIにするとオーナードローだらけになるので、やっぱり遅いように思います。
      （比較試験したことないので、経験則ですみません）
      PropertyChangedイベントはリフレクションを使うので確かに遅いですが、
      WPFのフレームワーク自体は依存関係プロパティを使っているので、高速に動作する設計になっていると記憶しています。
      
      WPFのメリットは
      １．Win32でリッチなUIを作るのは大変なので、その分の手間を軽減してくれる
      ２．MVVMを適用することで、ロジックの分離ができる（再利用可能なコードを増やす）
      ３．グラフィックボードに描画処理をさせるのでCPUの負荷を下げつつ高速に描画できる。
      で、基本的には使わない手は無いと思っています。
      
      と言いつつ、私が作成したアプリも動作が遅いので、ソフトの設計に問題があるんだろうなと日々奮闘しています。
11. • 11. [管理人]
    • 2017/12/17 20:29
    • > Win32でも同じデザインのUIにするとオーナードローだらけになるので、やっぱり遅いように思います。
      
      感覚的には Win32 だと複雑な UI でも快適なのが多いんですよねー
      でも 全く同じことをすると Win32 でも結局遅くなりますよね
      Win32 だと WPF で Framework がやってくれてるところまで自分で作ることになるので そこでそのときにやりたい事向けにガチガチに最適化してしまえるので優秀なプログラマがたくさんいるような大規模なソフトウェアだとそういう部分で差があるんだろうと思います
      
      > PropertyChangedイベント
      
      私が特に感じてる重いところは初期化部分です
      ItemsSource に匿名型のリストを入れたときでもプロパティを読み出してくれるのでリフレクションしてるんだろうな と思うところです
      初期化は 最初の PropertyChanged と言えるので やっぱり PropertyChanged だけが遅いということでしょうか
      PropertyChanged だけとは言っても ウィンドウ開いたり操作したり と何かするごとに発生するのでここが遅いのがけっこう体感に影響するように思います
      
      > 基本的には使わない手は無い
      
      そうですよね
      大規模で快適が重要なブラウザみたいなソフトウェアなら WPF などで済ますのは難しいでしょうけど 個人で作りたいものがある というときに Win32 で画面作るだけにかなり時間をかけて というのは大変ですしね
      Win32 で活かせる資産があるとかでなければ簡単に使えて高機能な WPF で良いと思います
12. • 12. ななしさん
    • 2018/01/27 10:49
    • Visual Studio は WPF なんですね。
      JIT を省略できる事前コンパイルしてるってことはないですか？
      
13. • 13. アルビレオ
    • 2018/03/14 18:38
    • > 内部処理は全部 C++ で書いて～
      
      そもそもFormsとかWPFってのはUI周りの違いでして、描画だけでなくイベントの扱いなどもかなり違いますが、内部処理に関しては同じものにできなくもないです。(大変だろうけど)
      逆にエディタ部分は大きくWPFに依存しないと無理でしょう。
      
      VisualStudioがそこそこ速い理由は、たぶん「画面表示関係にXAMLをあまり使ってない」せいだと思います。
      ほとんどのウィンドウが自由に配置できるため、XAMLを使わず動的にコントロールを配置しているのでしょう。
      そのためXMLのパースという比較的重い処理を省いた「ネイティブWPF」みたいなものになっていると思われます。
      WPFのXAMLパースはコンパイル時ではなく実行時に行われるらしいので、画面遷移のたびにXAMLを読み直すようなことが行われてレスポンスが悪くなっているのかも。
14. • 14. [管理人]
    • 2018/03/15 01:05
    • なるほどなるほど
      WPF なのにあえて便利な XAML を使わないのですか
      
      XAML は BAML (Binary XAML) にコンパイルされてると思いますが これでも遅いのでしょうか
      
      たしか前に 実行中に外部ファイルの XAML 開いてその XAML のデザインを別ウィンドウでプレビュー表示するものを作ったことがあるのですが 体感だとコンパイル時に確定しているウィンドウを開くより遅かった気がするので一応高速化するための処理はされてるのかなと思ってるのですけど
15. • 15. アルビレオ
    • 2018/03/15 10:30
    • まあ「VSがWPFなのにそんなに遅くないのはなぜ」という疑問からの推測なので間違っているかもしれませんが、XAMLはバイナリ化してもXMLとしての構造は維持しているはずなのでその初期化には深くネストした階層をたどる必要があります。
      Formsで複雑な入れ子構造を作ってもInitializeComponet()では全部newして初期化して親コンテナに入れて…と直線的に初期化できるのとは差があるのかもしれません。
      
      あと考えられそうなのはWPFのコントロールはStyleが何重にも入れ子になっているものが多いので、高速化のために構造をシンプルにした独自コントロールを多用しているのかも。
      でもVSはテーマの切替えやフォントの変更など多くの部品の表示設定をまとめて変更する必要が多いから、標準コントロールでないとデメリットが大きそうなんですよね。
      
      あとWPFの遅い原因の一つがGridレイアウトパネル。使いやすいのでテンプレートが標準で配置していますが遅いです。
      親パネルが子コントロールにサイズを問い合わせてそれを元に割り当てサイズを決めて、そのサイズでいいかを子コントロールに聞いて…を繰り返すのはどのパネルも共通ですが、Gridは行単位列単位で複数のコントロールをまとめてサイズ調整が必要なため重くなります。列またぎや行またぎの配置があるとさらに大変そう。
      VSはGridを使ってるところがあまりなさそうなことも重くならない理由でしょうか。その一方でDockを使いまくってるのは一目瞭然ですね。
16. • 16. [管理人]
    • 2018/03/17 00:36
    • 参考になります
      
      Grid は便利なのでつい使いがちですが速度重視なら避けたほうがいいのですね
17. • 17. あ
    • 2018/09/22 09:02
    • いやいやvisualstudio重すぎだろ？
      2005→2016に切り替えたのだが、起動が遅すぎ。全部がWPFのせいかどうかはわからないけど、WPFで大規模なアプリを作るのためらうよ。
18. • 18. [管理人]
    • 2018/09/24 22:30
    • 2005 からだと大きく変わってそうですね
      私は 2008 を一瞬触れたような気がするくらいで 2010 がほぼ最初に使ったバージョンです
      とは言ってもこの頃は低スペックノート PC に入れていたのでまともな環境で使ったのはたしか 2015 からです
      なので昔との速度の変化はあまりわかってません
      
      起動は全体的に遅いですが インストールしてるものが多いと特に遅くなるみたいです
      せっかくだからといろいろ入れた PC はかなり遅いです
      逆に必要な最低限にするとけっこう早くなります
      遅いので community じゃなくて express 入れてる PC もあります
      無料版だと昔は C++ とか C# で別れていたのがいまじゃ全部まとまってる分 全部をロードする必要があるからですかね
19. • 19. ななしさん
    • 2018/10/07 14:52
    • 他のIDEも触ってるとVSは特別遅いとは感じないですね
      やっぱり機能もりもりつけるとどんな手段で作っていてもある程度は重くなるんだなーと思ってます