Support for different text rendering modes, current mode at least for me causes eye strain making new terminal unusable.
Example between terminal (left) and conemu (right):

Adding options to profiles.json:
{
...
"TextAntialiasMode": "D2D1_TEXT_ANTIALIAS_MODE_CLEARTYPE",
...
}
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 :)
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 :
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?
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.
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.
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.
Please also consider adding an option to completely disable antialiasing. Not everyone likes soapy text.
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
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.)
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.pngSample of WSL terminal (different theme but same text):
[image: image]
https://user-images.githubusercontent.com/139975/69378307-24236980-0c7c-11ea-9695-9fa48c226c2b.pngAs 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
.
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.
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?
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.
I wonder if rendering without antialiasing at all, a la mintty, would be possible as well, at least for certain fonts:

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:
cleartype into the settings before opening Terminal in the first place. No difference. I'm a little stuck.
@Legorooj if you have acrylic on, it won't use cleartype, see #5277
@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):

@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 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!
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.
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.
Most helpful comment
Please also consider adding an option to completely disable antialiasing. Not everyone likes soapy text.