奇妙なWindowsフォントレンダリングの問題（ビデオデモ付き）
ビデオデモを参照してください：vimeo.com/155636855
私はこの問題に長い間取り組んできましたが、今は外部の助けが欲しいです。
*これはVMテクノロジーとは関係ありません-投稿の最後に追加されたメモを参照してください*
添付の画像には、ワードパッドファイルの画像が並んでおり、テキストはアルファベット、小文字、大文字のすべての文字を表しています。左側の画像は、Windows 10ホスト（「ホスト」OS）で実行されているWindows 10仮想マシン（「ゲスト」OS）から取得したものです。右側の画像は、Windowsホストから取得したものです。
画像を拡大し、各文字の端の違いをよく見てください。左側は右側よりもはるかに滑らかです。簡単な結論にジャンプしたい場合は、CLEARTYPE IS NOT問題（以下のポイントを参照）、少なくとも「オン」と「オフ」の観点からではありません（つまり、ClearTypeに関連するレジストリ設定が関係している可能性がありますが、ClearTypeに関連するWindows UIには、両方が原因でこれが発生しているものはありません。マシンはClearType用に調整されており、ホストマシンとゲストマシンの両方でClearTypeがオンになっています）。
事実：
両方のOSが同じ無数のフォントTrueType（TTF）フォントファイルを使用しています
両方のOSが同じ画面解像度に設定されています。
これはWindowsビデオドライバーの問題だと思いましたが、最新のnVidiaドライバーを使用しており、ホストとゲストの両方でDirectX12を搭載した比較的ハイエンドのGeForceGTX560カードを実行しています。
両方のワードパッドファイルは、同じフォント、フォントサイズ、フォントスタイル、およびズーム（100％）を使用しています。
両方のWindows10 OSは、WindowsUpdateを使用して完全に更新されます。
ClearTypeは、Windowsホストと仮想マシンの両方でアクティブ（オン）です。 ClearTypeのさまざまな組み合わせ（ホストでオフにしてゲストでオフにする、およびその他すべての組み合わせ）を試しましたが、ゲストと比較してホストに表示されるラフエッジアーティファクトに変更はありません。
ゲストとホストのDPIの違いを認識していません。 Windowsに含まれているArialフォントなどの他のフォントは、ホスト上でのみ同様のラフエッジの問題を示します。問題を説明するためにMyriadProを選択しました。
両方のフォントの色は100％BLACK（＃000）です。
この問題は、TrueTypeフォントをレンダリングできるすべてのアプリケーションで発生します。例としてワードパッドを使用しましたが、MicrosoftPowerPointとTechSmithのCamtasiaでも発生します。
この問題はTrueTypeフォントとは関係ありません。これはOTFフォントでも発生します。
また、その価値については、リモートデスクトップセッション（RDP）を介して別のコンピューターからホストを表示するか、TeamViewerなどを使用してホストを表示するかは関係ありません。また、RDPまたはTeamViewerを使用しても、ゲストの動作は変わりません。
明らかに、ホストのフォントレンダリングサブシステムに問題があります。興味深いことに、ホストは、約1週間前（2016年2月初旬）にWindows 10 Enterpriseをインストールしてアップグレードするまで、Windows 7Ultimateマシンでした。同じホスト上の仮想マシンで実行されているWindows10にはフォントレンダリングの問題がないことをすでに見たので、Windows7からWindows10にこのようなアップグレードを行うことでフォントレンダリングの問題が修正されることを期待していました。残念ながら、Windows 10への更新ではフォントのレンダリングは修正されませんでした（Windows 10の新規インストールは行いませんでした。以前のOSファイルと設定を保持する更新を行いました）。
上記のすべての理由により、ホストOSのフォントレンダリングに関連するレジストリに破損、欠落、または誤った値があると思われますが、それは何でしょうか？
* 2016年2月12日追加*新品のハードドライブを取り出し、上記の「ホスト」と同じハードウェアにクリーンなWindows10インスタンスをインストールしましたランニング。新しいWindows10インスタンスは、Windows 10の仮想マシン（VM）インスタンスと同じように、滑らかなフォントを備えています。これは、マシンのハードウェアが右側のイメージの生成に問題を引き起こしていないこと、およびVM（または仮想化テクノロジー）は格差の理由ではありません。これで、Windows 10を搭載したハードドライブAが、起動して右側の画像を表示できる物理マシンにインストールされました。左側の画像を表示するために起動できる同じマシン上に、Windows10を搭載した2台目のハードドライブBがあります。
次に、その新しいハードドライブをワイプし、MicrosoftソースセットアップDVDからWindows 7Ultimateをインストールしました。また、画像を左にレンダリングします（正しく滑らかなフォント）。したがって、問題は、Windows 7のハードウェアに問題があり、Windows 10がそれを修正しないということではありません。Windows7を再インストールしても、Windows7のハードウェアにフォントの問題が表示されないことは明らかです。
したがって、仮想化はさておき、既存のホストマシンと「通常の」Windows 7/10マシンの間のフォントレンダリングサブシステムで何らかの破損が発生しているようです（既存のホストマシンはWindows 7Ultimateからアップグレードされたことを思い出してください） Windows 10 Enterpriseに移行し、アップグレードを行う前にWindows 7 Ultimateに問題が存在していました。実際、アップグレードによってこの問題が修正されることを期待していましたが、そうではありませんでした）。
私は自由な時間に主要なレジストリエントリの不一致を調べて比較しようとしますが、根本的な原因に焦点を当てるのを手伝ってくれる専門家からの意見を聞きたいと思っています。
ClearTypeフォントのレンダリングが大きなフォントサイズで非常にうまく機能することに気づいたことはありません...しかし、私のWin10では、コンピューターと同じです。
あなたが説明する振る舞いは、私の意見では、バグではありません...それは機能です:-)
次の画像を見てください。
画像1：ClearTypeレンダリングがオンです（画像をクリックして表示しますより良い）
ClearTypeがオンの場合、Windowsフォントレンダリングエンジンは、LCD R/G/Bサブピクセルを利用して、フォントレンダリングを最適化しようとします。左側の拡大画像を確認すると、次のことがわかります。各フォントに青みがかった/赤みがかったスムージングがあるのは、これはLCDサブピクセル構造（ サブピクセルレンダリングの詳細はこちら ）。
しかし、ご指摘のとおり、これは大きなフォントサイズではうまく機能しません。
ただし、フォントサイズが小さい場合でも非常にうまく機能します。
画像2：ClearTypeレンダリングがオフです（画像をクリックして表示しますより良い） 
ClearTypeレンダリングをオフにすると、WindowsフォントレンダリングエンジンはLCDサブピクセル構造の利用を停止し、フォントは（青みがかった/赤みがかったスムージングではなく）単純な灰色のスムージングになります。 。
これは大きなフォントサイズではうまく機能しますが、ファイル名のレンダリングやメニューのレンダリングなどを確認することで確認できるため、小さなフォントサイズでは非常にうまく機能しません...
さて、ゲストPCでフォントレンダリングが良く見えるという事実は、おそらくWindowsが物理的なLCD画面を検出した場合にのみClearTypeサブピクセルフォントレンダリングが有効になるという事実によるものです。仮想の場合pcは物理LCDを検出しません。おそらく、「標準」（グレースケール）フォントスムージングを使用します。
これで、WindowsにCleartype /サブピクセルスムージングの代わりに「標準/グレースケール」フォントスムージングを使用させることができますが、私のコンピューターでは何の違いもありません。グレースケールスムージングを強制すると、Cleartypeを無効にするのと同じ結果が得られます。コントロールパネル。 （ Cleartypeレンダリングを微調整するためのレジストリハックに関する詳細はこちら ）