2

現在、社内のERPシステムを新しいメジャーバージョンにアップグレードする作業を行っており、フロントエンドのUIはもちろんWPFを使って基礎を作っているところですが、Imageエレメントを使うのかXAMLPathオブジェクト(ベクターグラフィックス)を使うのか知りたいです。ソリューション アイコン (つまり、追加、削除、保存、複製、検索などのボタン アイコン)。あなたの経験から、どちらが優れているのか、その理由は何ですか?

4

2 に答える 2

3

私は CodeWarrior に同意しますが、この決定には次のような多くの要因があると思います。

  • 誰が画像を制作していますか？君は？もしそうなら、あなたのデザインの才能はどのように発揮されますか? 個人的には、見栄えの良いビットマップ アイコンを作成するという希望はありませんが、XAML でまずまず魅力的なアイコンを作成することができます。
  • アイコンをさまざまなサイズで表示する必要がありますか? その場合、XAML ははるかに鮮明にスケーリングする傾向があるため、多くの時間を節約できます。
  • 非常に小さな解像度でアイコンを表示する必要がありますか? その場合、XAML アイコンは実際にはあまり魅力的ではないかもしれません
  • XAML アイコンを使用すると、画像を組み合わせる必要がある場合や、画像の太さ、色を変更したり、無効になっているときに "グレー表示" するなど、画像を微妙に変更したりする必要がある場合に、より柔軟に対応できます。
  • 最後に、両方の長所を活かすことを妨げるものは何もありません。私のアプリケーションでは、多くの場所でプライマリ アイコンが必要になることがわかっていました。XAML で設計し、さまざまなサイズのビットマップとして吐き出す小さなサポート アプリを作成しました。これにより、アプリケーション アイコンとして使いやすくなり、必要なすべてのサイズ (デスクトップ アイコン、ウィンドウ アイコンなど) で鮮明に見えます。さらに、スプラッシュ スクリーンなど、アプリケーション自体で XAML リソースとして使用しました。
于 2012-04-14T08:27:54.653 に答える
2

It depends on the scope of the images you are planning to display. If you have a small number of images that are going to be displayed several thousand times, XAML paths make sense. If they are only a few images displayed a few times, XAML paths would take more time than it would be worth. Similarly if you have thousands of images that are only displayed once each, go with images as it would take forever to convert to XAML paths (unless you have a method to do it programmatically).

It sounds like you are using a small number of images a few times, so go with images. It doesn't really take a whole lot of processing power to do it, and the big benefit of WPF is that it offloads graphic rendering stuff to the GPU instead of using the CPU for it.

于 2012-04-14T06:14:08.640 に答える