none
ソースコードの文字色が拡大率によって異なる RRS feed

  • 質問

  • Visual Studio Community 2019 VerSion 16.3.10を使用しています。

    特にフォントおよび色の設定などを変えず使用しているのですが、バージョンを更新したせいか特定の環境でソースコードの色が妙になるようになりました。
    以下の2つのソースコードは同じ内容で、ctrl+ホイールで拡大率だけを変えたものです。

    上の画像の通常の拡大率ですが、変数名の部分がピンク味がかかっているように見えます。
    下の画像は拡大率を上げたものですが、変数名が白く表示されています。

    一方、変数型や初期値の部分は拡大率によって大きさが異なっているものの、色味については同じに見えます。

    *ここに画像があった

    この変数名の色が拡大率によって変わる現象を解決するにはどうすればよいでしょうか。

    • お客様のアカウントが確認されるまで、本文に画像やリンクを含むことはできません。って言われたので画像を消去しました。再現状況を記載していますので、よろしくお願いします。

    2019年11月27日 5:08

回答

  • 線が細くなるほど色化けの影響が強くなりますので、フォントサイズを上げたり、より高精細なモニタを高DPI設定で使うことを検討してみてください。基準サイズの線幅が 2px 以上となるようにしておくと、色化けを軽減できるかと思います。

    また、先の画像で行によって色味が異なっている理由は、それぞれの水平開始位置がサブピクセル単位で異なるためです。

    たとえば上記画像の中で、3 つの変数名は、このようにズレています。

    UISprite CustomerEmoteSprite =
    GameObject CustomerHukidasiSpriteObject =
    UILabel CustomerHukidasiLabel =

    そこから、 Customer の「t」の部分をくり貫いて拡大してみます。
    背景の黒色部は #1E1E1E で、文字の白色部は #DCDCDC です。


    3 行目は、描画位置が整数座標だったらしく、白色(r=DC, g=DC, b=DC)で描画されており、文字幅も 1px でした。

    2 行目は、薄い水色と茶色の 2px で描画されています。(前回上げた画像と同じもの)
    サブピクセルに分解すると、r=9A, g=DC, b=DC, r=A7, g=1E, b=1E です。

    1 行目は、水色と茶色が鮮やかになっていますが、やはり 2px が消費されています。
    点灯画素は r=1E, g=BC, b=DC, r=DC, g=74, b=1E です。

    つまり サブピクセル単位で見てみると、それぞれの垂直線は、
     1 行目は 1px を「緑83%・青100%・赤100%・緑45%」の 4 つで

     2 行目は 1px を「赤65%・緑100%・青100%・赤72%」の 4 つで
     3 行目は 1px を「赤100%・緑100%・青100%」の 3 つで
    描画していることになります。(背景色1Eを0%、文字色DCを100%で換算)

    このため、1 行目は緑成分が強めに出て、2 行目は赤成分が強くなります。


    2019年11月28日 11:18

すべての返信

  • 上の画像の通常の拡大率ですが、変数名の部分がピンク味がかかっているように見えます。
    下の画像は拡大率を上げたものですが、変数名が白く表示されています。

    投稿時刻から想像すると、この画像でしょうか。
    (サイズの大きい画像の方が、先にアップロードされていました)


    フォント設定およびアンチエイリアスのかかり具合によって、色味が多少変わるのは仕方ないですが、一応、テキストのレンダリングに影響を与えそうな項目の例を挙げておきます。

    • Visual Studio の[ツール]-[オプション] の [環境]-[全般] の [視覚的効果] で、レンダリングがハードウェアとソフトウェアのいずれになっているか
    • Windows コントロール パネルの [ClearType テキストの調整] の設定
    2019年11月27日 6:59
  • 画像について補足していただき、ありがとうございます。その画像で間違いありません。

    また、ご指摘いただいた改善方法について、
    Visual Studio の[視覚的効果] については、「レンダリングがハードウェアとソフトウェア」といった項目は見つかりませんでした。
    代わりに、「レンダリング」という言葉が含まれる、「ピクセルの密度が異なる画面のレンダリングを最適化する(再起動が必要)」の項目のチェックを外し、PCの再起動しましたが、改善されませんでした。

    「ClearType テキストの調整」については有効な状態だったため、無効にしたところ色味については改善されたものの、ソースコードの文字がぼやけるようになり、余計に見にくくなりました。

    したがって、どちらの方法でも解決することがきませんでした。
    引き続き、回答を頂ければと思います。

    2019年11月27日 13:21
  • 御提供頂いた画像の「拡大率を上げたもの」の拡大率設定は幾つだったのでしょうか?

    OS の ClearType 設定は無効にするのではなく、有効にした上で調整するようにしてみてください。ここの調整で多少は軽減できるかも知れません(未確認)。

    お使いのディスプレイによっても異なりますが、普通の液晶画面の場合、青・赤・緑の 3 色(稀に 4 色)ラインが水平方向に並んでおり、3つとも点灯すると白い画素、全消灯で黒い画素を表します。サブピクセルレンダリングでは、水平方向のアンチエイリアスに対してこれを用いることで、文字のジャギーを軽減させる仕組みです。

    確認のため、当方の VS2019 (v16.3.10) の配色テーマを濃色に変更し、既定の拡大率(100%)表示、125%、150%、200% の拡大率という 4 パターンを、そちらの 2 枚の画像と比較してみました。

    違いが分かるよう、下記の画像では、さらに 8 倍に拡大していますが、水平方向の両端にサブピクセルでの描画が行われていることが見て取れます。

    同じ 100% でも、当方とそちらでサイズが違うようですが、これは恐らく、ディスプレイ設定の違いによるものです。

    当方のモニタ設定はドットバイドットな 100%(論理96DPI)設定ですが、
    そちらは 125%(論理120DPI)設定なのだと予想しています。

    • 当方の 100% 文字は、完全に白色(#DCDCDC)のみでレンダリングされていることが分かります。
    • 当方の 200% 文字は、垂直中央部が白色(#DCDCDC)で、周辺部がサブピクセルレンダリングされています。
    • 双方の 6 パターンとも、水平線は白色(#DCDCDC)でレンダリングされています。

    OS の設定変更でも軽減効果が無い場合は、十分に太い文字となるようなサイズまたはフォントを指定するようにするか、あるいは、ディスプレイ設定を 100% や 200% といったキリの良い設定にすることで、色化けの影響を削減できるとは思います。

    ちなみに、OS のバージョンによってフォント描画結果が変わってくることもあるそうです。(この点が Visual Studio の描画結果に影響があるかは未確認)

    2019年11月28日 2:54
  • ご回答ありがとうございます。

    まず、「ClearType 設定」について有効にしたうえで幾つかの表示を試してみましたが、いずれも改善されませんでした。
    つまり、Visual Studioの拡大率によって、ソースコードの文字の色味が変わったり、文字がぼやけるようになる状態です。

    モニターの設定ですが、「テキスト、アプリ、その他の項目のサイズを変更する」の項目が「100%(推奨)」で、ディスプレイの解像度が「1920×1080(推奨)」でした。
    使用しているモニターは一つだけで、これらの設定はデフォルトのまま、変更したことはありません。


    魔界の仮面弁士殿はアンチエイリアスが原因であるということで、確かに画面のスクリーンショットを撮り、画像を拡大するとアンチアイリエスがかかっていることがわかります。

    ただ、今回添付した画像をズームしていただければわかるように、「お客様のアカウントが確認されるまで、本文に画像やリンクを含むことはできません。」のせいで画像を消去するため、正常に確認していただけるかわかりませんが、連続した行の同じ形で記述した変数名にそれぞれ異なるアンチエイリアスがかかっており、このような処理が見にくさの一因となっています。
    これはモニターやOSが原因であるとは思えず、Visual Studio側の何らかの処理が原因ではないかと思います。

    ですので、Visual Studioの設定を変更することによりこの問題を解消できないでしょうか。

    2019年11月28日 8:40
  • 画像はこれでしょうか。(使われなかった添付ファイルは、しばらくすると削除されてしまうので、投稿に気付くのが遅れるとアップされた画像を追跡できなくなります)

    サブピクセル レンダリングの特性上、描画処理が整数座標上に無い場合には、描画開始位置によって、赤みが強くなるケース、青みが強くなるケース、緑が強く出るケースが生じることになります。もしも液晶画面の縦横を 90度回転させて表示させる設定にした場合、今度は垂直方向の周辺部が色化けすることになるでしょう。

    これは Visual Studio に限定した話ではありません。たとえば「サブピクセルレンダリング画像の落とし穴」というブログ記事において、『わかりやすい例として、このページを iPad 等の端末で表示させて、下の画像がどうなるかを見れば一目瞭然です。iPad の場合は、ホームボタンが右にあるときに正常に見え、ホームボタンが左にあるときに色が滲んで見えると思います。』というケースが挙げられています。

    さて、最初にアップロードされた画像を液晶の点灯イメージに加工してみると、こんなイメージになります。右側が、画面キャプチャによって得られた画像情報で、左側はそれを、液晶の赤/緑/青 の発光源ごとに分解してみたイメージです。

    画面キャプチャーから得た右側の画像では、垂直線が 2px の水色と黄土色で出力されてました。

    一方、RGB 成分に分解した左側の画像を見ると、明るく点灯している部分は、4 サブピクセル分であることが見て取れます。RGB のうち、緑成分が 1 つ余剰ではありますが、その分、垂直線の緑は、水平線の緑よりも暗く点灯していますね。(このあたりの色管理は、グラフィックドライバーによっても変わってくるかもしれません)



    それにしても、Visual Studio のバージョンは同じ、画面の DPI 設定も同じなのに、そちらの 100% とこちらの 100% の文字サイズが違うのは何故でしょうね。

    当方の環境は、Window 10 Pro ver 1809 (OS ビルド 18634.476) で、Visual Studio のフォント設定は、"MS ゴシック" の 10pt です。


    2019年11月28日 9:28
  • 線が細くなるほど色化けの影響が強くなりますので、フォントサイズを上げたり、より高精細なモニタを高DPI設定で使うことを検討してみてください。基準サイズの線幅が 2px 以上となるようにしておくと、色化けを軽減できるかと思います。

    また、先の画像で行によって色味が異なっている理由は、それぞれの水平開始位置がサブピクセル単位で異なるためです。

    たとえば上記画像の中で、3 つの変数名は、このようにズレています。

    UISprite CustomerEmoteSprite =
    GameObject CustomerHukidasiSpriteObject =
    UILabel CustomerHukidasiLabel =

    そこから、 Customer の「t」の部分をくり貫いて拡大してみます。
    背景の黒色部は #1E1E1E で、文字の白色部は #DCDCDC です。


    3 行目は、描画位置が整数座標だったらしく、白色(r=DC, g=DC, b=DC)で描画されており、文字幅も 1px でした。

    2 行目は、薄い水色と茶色の 2px で描画されています。(前回上げた画像と同じもの)
    サブピクセルに分解すると、r=9A, g=DC, b=DC, r=A7, g=1E, b=1E です。

    1 行目は、水色と茶色が鮮やかになっていますが、やはり 2px が消費されています。
    点灯画素は r=1E, g=BC, b=DC, r=DC, g=74, b=1E です。

    つまり サブピクセル単位で見てみると、それぞれの垂直線は、
     1 行目は 1px を「緑83%・青100%・赤100%・緑45%」の 4 つで

     2 行目は 1px を「赤65%・緑100%・青100%・赤72%」の 4 つで
     3 行目は 1px を「赤100%・緑100%・青100%」の 3 つで
    描画していることになります。(背景色1Eを0%、文字色DCを100%で換算)

    このため、1 行目は緑成分が強めに出て、2 行目は赤成分が強くなります。


    2019年11月28日 11:18
  • ご丁寧にありがとうございます。

    VSが原因とは限らないとのことで承知しました。
    環境について、フォント、フォントのサイズは同じでしたが、私はwindows10 homeでした。
    これか、モニターのドライバー辺りが原因で差異が出ているのかもしれません。

    解決策について、ソースコード1行を見て問題が起きないフォントサイズに変更するのは可能なのですが、
    2枚目の画像のように異なる長さの文字列が記述されている場合、それらすべてに問題が起きないフォントサイズにすると、作業が困難なレベルにズームしなければなりません。

    また、モニタの交換についてはすぐに対応するのが難しいため、とりあえずは気にしないで作業することにします。

    ありがとうございました

    2019年12月1日 3:03