しかし、人生は理想とはほど遠いものであり、通常、チームにはそのような人はいません（率直に言って、優れた「アイコンデザイナー」を見つけるのは非常に困難です）。
したがって、WPFアプリケーションでアイコンを使用した経験を一般の人々と共有し、おそらく自分自身からコメントのために何か新しいことを学びたいと思います。
ラスター
私たちはお気に入りのグラフィックエディターを用意し、透明な背景に必要なものを描画し、PNGで保存し、アプリケーションで画像を静かに使用します。
しかし、そこにはありませんでした-突然、さまざまな場所の私たちの写真をさまざまなサイズで表示する必要があることが判明しました。
最愛の写真モデルの顔ににきびを作ろうとした人は誰でも、小さな写真を拡大すると、すべてが「正方形」になることを知っています。
アプリケーションを古い8ビットゲームのように見せたくない場合は、小さな画像を増やすことは選択肢ではありません。
少し考えた後、「エウレカ！ 結局のところ、全体像を縮小することができます。」 そして袖をまくり、すべてのアイコンを最大サイズ（通常は64x64）に再描画します。
しかし、ここでは、物理学は私たちに反しています。 事実、モニターの製造元は（おそらく合意により）ピクセル数が固定されたモニターのみを作成でき、これらのピクセルもサイズが固定されています。
64x64イメージを32x32に縮小するとします。 つまり、元の画像で2 x 2の正方形を取り、それを縮小すると、1ピクセルになります（非常にラフですが、機能するようなものです）。
この変換により、情報の損失は避けられません。 その結果、画像が「ぼやける」か、一部の詳細が消えます。 正しく縮小される画像は、単色の64x64の正方形のみです。
どうする？ サイズごとに異なるアイコンを描画します。 オプションなし。 非常に明白な例は、メモ帳（Win7）を起動し、タスクバーに表示されるアイコンとウィンドウタイトルのアイコンを比較することです。
したがって、必要なすべてのサイズのアイコンを描画しましたが、私たちは平和に眠ることができるようです。 しかし、違います。 留意すべき点がさらに2つあります。
- アニメーション たとえば、マウスをホバーすると、画像は1.5倍に拡大されます。
- 非標準のDPIモニター。 ゆっくり（まあ、私のモニターが24インチで300DPIの場合は非常に遅くなります）それらは表示され始めます。主にモバイルデバイスとネットブックで。
残念ながら、上記の問題のいずれにも良い解決策はありません。 リラックスし
ベクトル
最初にWPFを試したとき、Xamlでボタンのアイコンを作成できたことを本当に嬉しく思いました。 これがすべての問題の解決策であると思われます。 しかし、そこにありました（ああ、あの物理学）。
まず、画像がベクター画像であっても、ラスタースクリーンに描画する必要があります（ラスター化）。 したがって、ベクトルアイコンは上記と同じ問題によって特徴付けられます。
一般に、サイズごとにアイコンを描画する必要があります。 SnapsToDevicePixelsをtrueに設定し、イメージ自体を単純化することにより、スケーリング時に許容可能な品質を実現することがしばしば可能ですが。
第二に、完全なパフォーマンスの問題が発生します。 ピクチャが数十個の要素で構成されている場合、同様のサイズのビットマップイメージを描画するよりもレンダリングのコストがはるかに高くなります。
幸いなことに、WPF開発者は、現在のところRenderOptions.CachingHint設定を提供および作成しています。 大まかに言えば、WPFに最初に画像をレンダリングするときに、結果をビットマップに保存してからこのビットマップを使用することをWPFに伝えることができます。
一般に、RenderOptionsとBitmapCacheBrushのドキュメントを読むことをお勧めします。
背景
最後に、キャプテン・ユー・ノウ・フーからのいくつかの言葉。 通常、アイコンは透明な背景で描画されますが、アイコンが最終的にレンダリングされる背景を忘れてはなりません。 可能なすべての背景（通常、ホバー、クリック、選択）でアイコンがどのように見えるかを確認してください。