WPFを使用してランダムアプリケーション用のGUIを開発しました。アプリケーションウィンドウに、すぐに使用できるWPFコントロールがたくさんあります。何もカスタマイズしていない、ビットマップを使用していないなど。
Windows 7で拡大鏡アプリケーションを使用してアプリケーションを実行してズームすると（Win key + Plus key、拡大されたGUIにピクセルが表示されます。他の方法で説明できないため、おそらく間違っていますが、WPFはコントロールレンダリングのようなベクトルを提供することになっていますか？
ディスカッションに参加していただきありがとうございます。
Vistaが最初に出荷されたとき、およびWPFがバージョン3.0であったとき、組み込みの拡大鏡を使用したズームは、実際にはベクトルベースのスケーリングを実行していました。
これは、WPF3.5サービスパック1が出荷されたときに機能しなくなりました。（sp1より前の3.5で機能しました。）それ以前に機能した理由は、画面に表示されるすべてのものを表示するWindowsの一部であるDWM（Desktop Window Manager）がMILCORE.DLLを使用してレンダリングを行うためです。WPFのバージョン3.0および3.5も、これと同じコンポーネントを使用してレンダリングしました。つまり、すべてのWPFコンテンツは、いわばネイティブコンテンツでした。（実際、DWMがないWindows XPでは、MILCORE.DLLは、WPFが独自の利益のためにシステムに配置するものです。ただし、VistaおよびWindows 7に組み込まれています。）WPFがMILCORE.DLLを使用してVistaでレンダリングすると、スケーリングなどのDWMによって適用される効果は、WPFで使用する方法でも適用されます。実際には、ピクセル化せずにスケーリングしました。
残念ながら、これはもはや当てはまりません。その理由は、WPFが新しいレンダリング機能の追加を開始したためです。3.5 sp1では、問題の新機能はカスタムピクセルシェーダーのサポートでした。これを有効にするには、MicrosoftはMILの更新をリリースする必要がありました。（メディア統合レイヤー-実際のレンダリングを行うビット。）ただし、MILCORE.DLLはWindowsの一部であるため、実際には更新することができませんでした。これにより、画面に表示されるすべてのものが画面に表示されます。MILCORE.DLLの新しいバージョンをリリースすることは、事実上、Windowsへの更新をプッシュすることを意味します。Windowsのリリーススケジュールは.NETのリリーススケジュールとは独立しているため、WPFチームが新しい機能を合理的に追加できる唯一の方法は、新しいMILを出荷することでした。（理論的には、WindowsUpdateを介してそれを行うことができたはずです。
.NET 3.5 sp1の時点で、MILはwpf_gfx_vXXXX.dllと呼ばれる別のDLLにあります。ここで、vXXXXはバージョン番号です。.NET 4.0では、wpf_gfx_v0400.dllです。
利点は、WPFが、Windows自体を更新しなくても、新しいバージョンごとに新しいレンダリング機能を追加できることです。欠点は、WPFのレンダリングが、Vistaの出荷時に一時的に戻ったときほどWindowsと緊密に統合されていないことです。そして、結果として、あなたが見てきたように、拡大は以前ほど楽しくはありません。
拡大鏡アプリケーションは、独自のズーム画像レンダリングを実装しているため、ピクセルが表示されます。WPFはベクターグラフィックを使用しますが、この状況では、ズームされた画像をレンダリングしているのはWPFアプリケーション自体ではありません。
Snoopのようなものを使用すると、ズームおよびスケーリングされたWPFベクターグラフィックスレンダリングの動作を確認できます。
Windows 7拡大鏡は、実際のアプリケーションの画面上のUIのスナップショットを取得し、それ自体を拡大します（WPFアプリケーションの特別な場合は作成しません）。もちろん、アクセスできるのはピクセルだけであり、舞台裏で機能するベクターグラフィックではありません。
Windows-7-Magnifierはピクセルベースですが、Aero-themeがアクティブかどうかによって、拡大鏡モードに違いがあります。
Areoテーマでのみ、他のビュー（「ドッキング」を除く）を選択できます。