Feature Request: Antialiasing mode options #1721

@zadjii-msft commented on GitHub (Jun 18, 2019):

I think this is a really good idea, and one that @miniksa and I have definitely discussed before.

I'd probably want to make the settings values a little clearer than "D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE", but that we could hash out in a PR I think :)

@zadjii-msft commented on GitHub (Jun 18, 2019): I think this is a really good idea, and one that @miniksa and I have definitely discussed before. I'd probably want to make the settings values a little clearer than `"D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE"`, but that we could hash out in a PR I think :)

claunia commented

https://docs.microsoft.com/en-us/windows/desktop/api/d2d1/ne-d2d1-d2d1_text_antialias_mode

@hwti commented on GitHub (Jun 22, 2019):

If the render target has an alpha channel and is not set to D2D1_ALPHA_MODE_IGNORE, then the default text antialiasing mode is grayscale.

Maybe that's the issue here.

It would be nice if we could set the DWRITE_RENDERING_MODE/DWRITE_MEASURING_MODE too.
For example, look at text rendering in Firefox and Chrome, both using DirectWrite, even in cases when they both enable ClearType : Firefox uses the "GDI classic" mode in some cases :

gfx.font_rendering.cleartype_params.force_gdi_classic_for_families = Arial,Consolas,Courier New,Microsoft Sans Serif,Segoe UI,Tahoma,Trebuchet MS,Verdana
gfx.font_rendering.cleartype_params.force_gdi_classic_max_size = 15

@hwti commented on GitHub (Jun 22, 2019): https://docs.microsoft.com/en-us/windows/desktop/api/d2d1/ne-d2d1-d2d1_text_antialias_mode > If the render target has an alpha channel and is not set to D2D1_ALPHA_MODE_IGNORE, then the default text antialiasing mode is grayscale. Maybe that's the issue here. It would be nice if we could set the `DWRITE_RENDERING_MODE`/`DWRITE_MEASURING_MODE` too. For example, look at text rendering in Firefox and Chrome, both using DirectWrite, even in cases when they both enable ClearType : Firefox uses the "GDI classic" mode in some cases : - gfx.font_rendering.cleartype_params.force_gdi_classic_for_families = Arial,Consolas,Courier New,Microsoft Sans Serif,Segoe UI,Tahoma,Trebuchet MS,Verdana - gfx.font_rendering.cleartype_params.force_gdi_classic_max_size = 15

claunia commented

@Lombra commented on GitHub (Jun 24, 2019):

My heart sank the moment I first opened Windows Terminal and witnessed this awful text rendering method that's prevalent in Chromium based applications. (notably Electron based apps) Glad to hear it might get fixed.

Is there a scenario in which the blurry rendering is required, or why is it used? Is the clear text not objectively better looking?

@Lombra commented on GitHub (Jun 24, 2019): My heart sank the moment I first opened Windows Terminal and witnessed this awful text rendering method that's prevalent in Chromium based applications. (notably Electron based apps) Glad to hear it might get fixed. Is there a scenario in which the blurry rendering is required, or why is it used? Is the clear text not objectively better looking?

claunia commented

@miniksa commented on GitHub (Jun 24, 2019):

Grayscale rendering is significantly faster than ClearType. You also cannot mix ClearType with alpha blending of the background.

This should be offered as a user preference for sure because everyone has their own tastes when it comes to text rendering.

@miniksa commented on GitHub (Jun 24, 2019): Grayscale rendering is significantly faster than ClearType. You also cannot mix ClearType with alpha blending of the background. This should be offered as a user preference for sure because everyone has their own tastes when it comes to text rendering.

claunia commented

@hwti commented on GitHub (Jun 24, 2019):

You also cannot mix ClearType with alpha blending of the background.

But IHMO it makes sense to use "GDI classic" rendering mode to disable subpixel positioning (and perhaps a stronger hinting) in this case, especially for a monospace font.

@hwti commented on GitHub (Jun 24, 2019): > You also cannot mix ClearType with alpha blending of the background. But IHMO it makes sense to use "GDI classic" rendering mode to disable subpixel positioning (and perhaps a stronger hinting) in this case, especially for a monospace font.

claunia commented

@miniksa commented on GitHub (Jun 24, 2019):

You also cannot mix ClearType with alpha blending of the background.

But IHMO it makes sense to use "GDI classic" rendering mode to disable subpixel positioning (and perhaps a stronger hinting) in this case, especially for a monospace font.

That might also be a user preference. Maybe someone likes subpixel positioning. Maybe the default should be GDI Classic. To be honest, I haven't thought that hard about this specific topic while standing up the renderer, so it hasn't been addressed.

If someone has strong reasons one way or another, I'd love to hear them. Or I'd love to see someone try them out and prove why one beats the other handily. Or offer both as choices.

@miniksa commented on GitHub (Jun 24, 2019): > > You also cannot mix ClearType with alpha blending of the background. > > But IHMO it makes sense to use "GDI classic" rendering mode to disable subpixel positioning (and perhaps a stronger hinting) in this case, especially for a monospace font. That might also be a user preference. Maybe someone likes subpixel positioning. Maybe the default should be GDI Classic. To be honest, I haven't thought that hard about this specific topic while standing up the renderer, so it hasn't been addressed. If someone has strong reasons one way or another, I'd love to hear them. Or I'd love to see someone try them out and prove why one beats the other handily. Or offer both as choices.

claunia commented

@svofski commented on GitHub (Jun 30, 2019):

Please also consider adding an option to completely disable antialiasing. Not everyone likes soapy text.

@svofski commented on GitHub (Jun 30, 2019): Please also consider adding an option to completely disable antialiasing. Not everyone likes soapy text.

claunia commented

@george-tsiros commented on GitHub (Sep 3, 2019):

call me crazy, but i think it should by default obey the system-wide settings and if they want to do something different, obey the user's choice

@george-tsiros commented on GitHub (Sep 3, 2019): call me crazy, but i think it should **by default** obey the system-wide settings and if they want to do something different, **obey the user's choice**

claunia commented

@garyo commented on GitHub (Nov 21, 2019):

Is this why my Windows Terminal fonts look vertically stretched? I use Hack, size 10. In Windows Terminal the lowercase "e" is 8 pixels high. In all other apps (Emacs, WSL terminal etc.), lowercase "e" is 7 pixels high (and is ClearType-antialiased rather than monochrome). Sample of Windows Terminal (0.6.2951.0):

Sample of WSL terminal (different theme but same text):

As you can see, the same font is significantly taller in Windows Terminal. (The prompt line is also rendered in bold in WSL, but look at the echoed text -- that's not bold in both samples, so should be comparable.)

@garyo commented on GitHub (Nov 21, 2019): Is this why my Windows Terminal fonts look vertically stretched? I use Hack, size 10. In Windows Terminal the lowercase "e" is 8 pixels high. In all other apps (Emacs, WSL terminal etc.), lowercase "e" is 7 pixels high (and is ClearType-antialiased rather than monochrome). Sample of Windows Terminal (0.6.2951.0): ![image](https://user-images.githubusercontent.com/139975/69378273-18d03e00-0c7c-11ea-846c-9dee6cd647e2.png) Sample of WSL terminal (different theme but same text): ![image](https://user-images.githubusercontent.com/139975/69378307-24236980-0c7c-11ea-9695-9fa48c226c2b.png) As you can see, the same font is significantly taller in Windows Terminal. (The prompt line is also rendered in bold in WSL, but look at the echoed text -- that's not bold in both samples, so should be comparable.)

claunia commented

@george-tsiros commented on GitHub (Nov 21, 2019):

that could very well be a different font size.

the fact that you ask for a size "10" font doesn't mean anything.

yes, theoretically it does mean something and they will claim it refers
to, again, something, but if you get an answer to the question "why does
every program render a size 10 font to different sizes, then?", i will
shave my scrotum with a rusty spoon and some tabasco.

On Thu, Nov 21, 2019, 23:31 GaryO notifications@github.com wrote:

Is this why my Windows Terminal fonts look vertically stretched? I use
Hack, size 10. In Windows Terminal the lowercase "e" is 8 pixels high. In
all other apps (Emacs, WSL terminal etc.), lowercase "e" is 7 pixels high
(and is ClearType-antialiased rather than monochrome). Sample of Windows
Terminal (0.6.2951.0):
[image: image]
https://user-images.githubusercontent.com/139975/69378273-18d03e00-0c7c-11ea-846c-9dee6cd647e2.png

Sample of WSL terminal (different theme but same text):
[image: image]
https://user-images.githubusercontent.com/139975/69378307-24236980-0c7c-11ea-9695-9fa48c226c2b.png

As you can see, the same font is significantly taller in Windows Terminal.
(The prompt line is also rendered in bold in WSL, but look at the echoed
text -- that's not bold in both samples, so should be comparable.)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/1298?email_source=notifications&email_token=AM77DI462LU4ZXLRVUUUYSTQU343XA5CNFSM4HYWYCC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE3W6DQ#issuecomment-557281038,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM77DI3JVXGTAQV7C3WZWI3QU343XANCNFSM4HYWYCCQ
.

@george-tsiros commented on GitHub (Nov 21, 2019): that could very well be a different font size. the fact that you ask for a size "10" font doesn't mean anything. yes, theoretically it does mean *something* and they will claim it refers to, again, *something*, but if you get an answer to the question "why does every program render a size 10 font to different sizes, then?", i will shave my scrotum with a rusty spoon and some tabasco. On Thu, Nov 21, 2019, 23:31 GaryO <notifications@github.com> wrote: > Is this why my Windows Terminal fonts look vertically stretched? I use > Hack, size 10. In Windows Terminal the lowercase "e" is 8 pixels high. In > all other apps (Emacs, WSL terminal etc.), lowercase "e" is 7 pixels high > (and is ClearType-antialiased rather than monochrome). Sample of Windows > Terminal (0.6.2951.0): > [image: image] > <https://user-images.githubusercontent.com/139975/69378273-18d03e00-0c7c-11ea-846c-9dee6cd647e2.png> > > Sample of WSL terminal (different theme but same text): > [image: image] > <https://user-images.githubusercontent.com/139975/69378307-24236980-0c7c-11ea-9695-9fa48c226c2b.png> > > As you can see, the same font is significantly taller in Windows Terminal. > (The prompt line is also rendered in bold in WSL, but look at the echoed > text -- that's not bold in both samples, so should be comparable.) > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/1298?email_source=notifications&email_token=AM77DI462LU4ZXLRVUUUYSTQU343XA5CNFSM4HYWYCC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE3W6DQ#issuecomment-557281038>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AM77DI3JVXGTAQV7C3WZWI3QU343XANCNFSM4HYWYCCQ> > . >

claunia commented

@garyo commented on GitHub (Nov 21, 2019):

the fact that you ask for a size "10" font doesn't mean anything.

Well yes, it's possible of course. I do understand in some detail how Windows TrueType font creation/selection works though; and the fact that these samples have (almost) the same width but different heights suggests to me that something else is at work here. And in every other Windows program I use that font in (OneNote, Word and some web apps, as well as the examples I gave above), it does not come out vertically stretched like that.

@garyo commented on GitHub (Nov 21, 2019): > the fact that you ask for a size "10" font doesn't mean anything. Well yes, it's possible of course. I do understand in some detail how Windows TrueType font creation/selection works though; and the fact that these samples have (almost) the same width but different heights suggests to me that something else is at work here. And in every other Windows program I use that font in (OneNote, Word and some web apps, as well as the examples I gave above), it does not come out vertically stretched like that.

claunia commented

@Arcitec commented on GitHub (Dec 6, 2019):

Opened Windows Terminal for the first time today. My first impression was that something is very wrong. Then I realized the text looked awful, as if I need to wear glasses because the text is out of focus. Tried changing font to no avail. :-/

I don't understand the comments above. Did you say that this antialiasing/blur is necessary to allow acrylic backgrounds to work?

I hope the text can be made sharp with a better anti aliasing algorithm. Like in notepad.exe, which is rendering crisply antialiased text. I don't think Terminal is supposed to be so blurry in comparison, right?

@Arcitec commented on GitHub (Dec 6, 2019): Opened Windows Terminal for the first time today. My first impression was that something is very wrong. Then I realized the text looked awful, as if I need to wear glasses because the text is out of focus. Tried changing font to no avail. :-/ I don't understand [the comments above](https://github.com/microsoft/terminal/issues/1298#issuecomment-505119476). Did you say that this antialiasing/blur is necessary to allow acrylic backgrounds to work? I hope the text can be made sharp with a better anti aliasing algorithm. Like in notepad.exe, which is rendering crisply antialiased text. I don't think Terminal is supposed to be so blurry in comparison, right?

claunia commented

@melak47 commented on GitHub (Dec 7, 2019):

Did you say that this antialiasing/blur is necessary to allow acrylic backgrounds to work?

No -- ClearType works fine on the acrylic background. The alpha blending only comes into play in the titlebar IIRC (when drawing over the standard titlebar), but I think that should be fine, too, since any area where text is drawn into the titlebar is entirely covered by an opaque background color.

You can build the terminal yourself, replace the single use of D2D1_TEXT_ANTIALIAS_MODE_GRAYSCALE with D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE, and see this result:

In the titlebar, it still uses grayscale AA. I haven't looked enough to be able to say if this is because of alpha blending problems, or if that text is drawn differently and doesn't use this AA mode because of that.

@melak47 commented on GitHub (Dec 7, 2019): > Did you say that this antialiasing/blur is necessary to allow acrylic backgrounds to work? No -- ClearType works fine on the acrylic background. The alpha blending only comes into play in the titlebar IIRC (when drawing over the standard titlebar), but I think that *should* be fine, too, since any area where text is drawn into the titlebar is entirely covered by an opaque background color. You can build the terminal yourself, replace the single use of `D2D1_TEXT_ANTIALIAS_MODE_GRAYSCALE` with `D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE`, and see this result: ![term](https://user-images.githubusercontent.com/3340026/70368457-f3ae1300-18aa-11ea-8068-d564b21e656f.png) In the titlebar, it still uses grayscale AA. I haven't looked enough to be able to say if this is because of alpha blending problems, or if that text is drawn differently and doesn't use this AA mode because of that.

claunia commented

@carlescufi commented on GitHub (Feb 17, 2020):

I wonder if rendering without antialiasing at all, a la mintty, would be possible as well, at least for certain fonts:

@carlescufi commented on GitHub (Feb 17, 2020): I wonder if rendering without antialiasing at all, a la mintty, would be possible as well, at least for certain fonts: ![image](https://user-images.githubusercontent.com/12450381/74646179-a0452480-5179-11ea-9f9b-91003d887fac.png)

claunia commented

@Legorooj commented on GitHub (May 21, 2020):

I'm still seeing this when running the very latest terminal 1.0.1401.0 when using "antialiasingMode": "cleartype" on every profile in my settings.json.

Every single profile in profiles.list has "antialiasingMode": "cleartype" set, and it's set in profiles.defaults.

I tried:

Updating - I was seeing this last version as well (0.11.x?) - and that made no difference.
Reinstalling and editing cleartype into the settings before opening Terminal in the first place. No difference.
Nearly an hour on Google - this and related threads primarily - with no result.

I'm a little stuck.

@Legorooj commented on GitHub (May 21, 2020): I'm still seeing this when running the very latest terminal 1.0.1401.0 when using `"antialiasingMode": "cleartype"` on every profile in my `settings.json`. Every single profile in `profiles.list` has `"antialiasingMode": "cleartype"` set, *and* it's set in `profiles.defaults`. I tried: * Updating - I was seeing this last version as well (0.11.x?) - and that made no difference. * Reinstalling and editing `cleartype` into the settings before opening Terminal in the first place. No difference. * Nearly an hour on Google - this and related threads primarily - with no result. I'm a little stuck.

claunia commented

@melak47 commented on GitHub (May 21, 2020):

@Legorooj if you have acrylic on, it won't use cleartype, see #5277

@melak47 commented on GitHub (May 21, 2020): @Legorooj if you have acrylic on, it won't use cleartype, see #5277

claunia commented

@Legorooj commented on GitHub (May 22, 2020):

@melak47

"defaults":
{
    // Put settings here that you want to apply to all profiles.
    "antialiasingMode": "cleartype",
    "useAcrylic": false
},

The error still occurs (several relaunches. I also tried setting it individually for each profile):

@Legorooj commented on GitHub (May 22, 2020): @melak47 ``` "defaults": { // Put settings here that you want to apply to all profiles. "antialiasingMode": "cleartype", "useAcrylic": false }, ``` The error still occurs (several relaunches. I also tried setting it individually for each profile): ![PowerShell 21_05_2020 5_34_34 PM](https://user-images.githubusercontent.com/50370070/82629398-f7eca380-9c32-11ea-9c24-6f207a350b26.png)

claunia commented

@miniksa commented on GitHub (May 29, 2020):

@melak47
"defaults":
{
    // Put settings here that you want to apply to all profiles.
    "antialiasingMode": "cleartype",
    "useAcrylic": false
},
The error still occurs (several relaunches. I also tried setting it individually for each profile):

@Legorooj, that's not a cleartype error. That screenshot is of the problem in #5759.
You can try the rendering settings documented behind https://docs.microsoft.com/en-us/windows/terminal/troubleshooting#the-text-is-blurry to set either full repaints or software rendering to mitigate that until we can fully understand what is causing some graphics drivers to blur out the previous frames of our rendering.

@miniksa commented on GitHub (May 29, 2020): > @melak47 > > ``` > "defaults": > { > // Put settings here that you want to apply to all profiles. > "antialiasingMode": "cleartype", > "useAcrylic": false > }, > ``` > > The error still occurs (several relaunches. I also tried setting it individually for each profile): > > ![PowerShell 21_05_2020 5_34_34 PM](https://user-images.githubusercontent.com/50370070/82629398-f7eca380-9c32-11ea-9c24-6f207a350b26.png) @Legorooj, that's not a cleartype error. That screenshot is of the problem in #5759. You can try the rendering settings documented behind https://docs.microsoft.com/en-us/windows/terminal/troubleshooting#the-text-is-blurry to set either full repaints or software rendering to mitigate that until we can fully understand what is causing some graphics drivers to blur out the previous frames of our rendering.

claunia commented

@Legorooj commented on GitHub (May 30, 2020):

@miniksa thanks for that - somehow I didn't come across that issue or the settings page. Using forced software rendering seems to have fixed the problem. Thanks!

@Legorooj commented on GitHub (May 30, 2020): @miniksa thanks for that - somehow I didn't come across that issue or the settings page. Using forced software rendering seems to have fixed the problem. Thanks!

claunia commented

@george-tsiros commented on GitHub (May 30, 2020):

pixel center offset, texture resize, texturemin/mag filter, texture
compression, glViewport, data type when packing/unpacking pixels, dpi
settings, are some of the things that come to mind. On amd hardware there
is an option in their control panel, "morphological filtering" that may
interfere

i've spent unhealthy amounts of effort and time rendering text as sharp as
possible.

i've concluded that unless you plan on running behind the gpu vendors every
time they change something, the only feasible method is software rendering
with simd, blitting, raster fonts, and dirty rects. In short, the oldest
methods known.

@george-tsiros commented on GitHub (May 30, 2020): pixel center offset, texture resize, texturemin/mag filter, texture compression, glViewport, data type when packing/unpacking pixels, dpi settings, are some of the things that come to mind. On amd hardware there is an option in their control panel, "morphological filtering" that may interfere i've spent unhealthy amounts of effort and time rendering text as sharp as possible. i've concluded that unless you plan on running behind the gpu vendors every time they change something, the only feasible method is software rendering with simd, blitting, raster fonts, and dirty rects. In short, the oldest methods known.

claunia commented

@mic345 commented on GitHub (Jul 10, 2020):

Question -- some people turn off the "smooth edge of screen fonts" option available on the "Performance Options", so the fonts look pixeleted but crystal sharp. From what I saw the fonts stay the same with this option turned on or off. Can you please check if this is causing the fonts to look smudge?

Take care and awesome terminal you've got there 👍
Mic.

@mic345 commented on GitHub (Jul 10, 2020): Question -- some people turn off the "smooth edge of screen fonts" option available on the "Performance Options", so the fonts look pixeleted but crystal sharp. From what I saw the fonts stay the same with this option turned on or off. Can you please check if this is causing the fonts to look smudge? Take care and awesome terminal you've got there 👍 Mic.

claunia commented

@ofek commented on GitHub (Jun 19, 2022):

if you have acrylic on, it won't use cleartype, see https://github.com/microsoft/terminal/pull/5277

is that still the case?

@ofek commented on GitHub (Jun 19, 2022): > if you have acrylic on, it won't use cleartype, see https://github.com/microsoft/terminal/pull/5277 is that still the case?

claunia commented

@seabdelh commented on GitHub (Jul 15, 2022):

not sure if this old issue got closed because of a fix or just inactivity, but the issue is happening to me as well

in comparison, iv tried Fluent Terminal, and I get sharp fonts, no blur....so why only Windows terminal is having this issue

I am thinking it's something with DPI scaling, since for FT for the same font I am using bigger font size(16), while for WT I had to use smaller font size(only 11) otherwise I get very big font

also checking DPI awareness column for both in windows task manager yields different values

@seabdelh commented on GitHub (Jul 15, 2022): not sure if this old issue got closed because of a fix or just inactivity, but the issue is happening to me as well ![image](https://user-images.githubusercontent.com/16710449/179295385-38e3940e-98b0-4412-92ed-37c5b2474ed2.png) in comparison, iv tried Fluent Terminal, and I get sharp fonts, no blur....so why only Windows terminal is having this issue ![image](https://user-images.githubusercontent.com/16710449/179296551-8e925d83-2ac9-4b9f-9fc9-b9b5b2a8c036.png) I am thinking it's something with DPI scaling, since for FT for the same font I am using bigger font size(16), while for WT I had to use smaller font size(only 11) otherwise I get very big font also checking DPI awareness column for both in windows task manager yields different values ![image](https://user-images.githubusercontent.com/16710449/179297211-38a7eea8-0924-49f0-9848-4e93309d9302.png) ![image](https://user-images.githubusercontent.com/16710449/179297282-b31119fb-e406-4c7f-ab03-f9611dc1447d.png)

claunia commented

@zadjii-msft commented on GitHub (Jul 15, 2022):

That doesn't look like antialiasing to me, that looks like you've got a custom scaling factor set, see #4591

@zadjii-msft commented on GitHub (Jul 15, 2022): That doesn't look like antialiasing to me, that looks like you've got a custom scaling factor set, see #4591

claunia commented