Do user research on AtlasEngine usage #18390

@lhecker commented on GitHub (Sep 7, 2022):

Are you sure you tried the latest version from the main branch?

@lhecker commented on GitHub (Sep 7, 2022): Are you sure you tried the latest version from the main branch? ![image](https://user-images.githubusercontent.com/2256941/188866606-38b37655-b785-484a-b233-eaf93932c8d5.png)

claunia commented

@237dmitry commented on GitHub (Sep 7, 2022):

Are you sure you tried the latest version from the main branch?

Windows 11 (10.22000)
Windows Terminal Preview
Version: 1.15.2283.0

PS >  (Get-Item 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.15.2283.0_x64__8wekyb3d8bbwe\wt.exe').VersionInfo.ProductVersion

1.15.220816003-preview

Is there a later version?

@237dmitry commented on GitHub (Sep 7, 2022): > Are you sure you tried the latest version from the main branch? Windows 11 (10.22000) Windows Terminal Preview Version: 1.15.2283.0 ```powershell PS > (Get-Item 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.15.2283.0_x64__8wekyb3d8bbwe\wt.exe').VersionInfo.ProductVersion 1.15.220816003-preview ``` Is there a later version?

claunia commented

@lhecker commented on GitHub (Sep 7, 2022):

Is there a later version?

We first develop features here on GitHub and then, every so often, we create a snapshot that we release in the App Store. In other words, the main branch on GitHub includes all the latest changes, whereas the App Store release might lag behind by up to 2 months.
The 1.15 series that you use for instance was forked off on the 2022-07-01. Since then development has continued on the main branch here on GitHub, which will end up being 1.16. After 1.16 has been forked off of main, the main branch will continue to receive all the latest changes again and then end up being 1.17 in the future. In short, the store releases always lag behind GitHub code changes by a bit.
1.16 will be released approximately next week.

@lhecker commented on GitHub (Sep 7, 2022): > Is there a later version? We first develop features here on GitHub and then, every so often, we create a snapshot that we release in the App Store. In other words, the `main` branch on GitHub includes all the latest changes, whereas the App Store release might lag behind by up to 2 months. The 1.15 series that you use for instance was forked off on the 2022-07-01. Since then development has continued on the `main` branch here on GitHub, which will end up being 1.16. After 1.16 has been forked off of `main`, the `main` branch will continue to receive all the latest changes again and then end up being 1.17 in the future. In short, the store releases always lag behind GitHub code changes by a bit. 1.16 will be released approximately next week.

claunia commented

@zadjii-msft commented on GitHub (Sep 8, 2022):

#13939 was a great start, I'm gonna move this to 1.17 for any follow up ideas we have.

@zadjii-msft commented on GitHub (Sep 8, 2022): #13939 was a great start, I'm gonna move this to 1.17 for any follow up ideas we have.

claunia commented

@dstanberry commented on GitHub (Sep 15, 2022):

Windows Terminal Preview
Version: 1.16.2523.0

With AtlasEngine enabled, double width glyphs are shrunk to fit within a single cell. Is this the desired behavior?

Atlas enabled:

Atlas disabled:

@dstanberry commented on GitHub (Sep 15, 2022): Windows Terminal Preview Version: 1.16.2523.0 With AtlasEngine enabled, double width glyphs are shrunk to fit within a single cell. Is this the desired behavior? Atlas enabled: ![2022-09-14_21-33](https://user-images.githubusercontent.com/22458241/190300298-337fb2f1-b41d-44f9-9039-d900b918ca45.png) Atlas disabled: ![2022-09-14_21-34](https://user-images.githubusercontent.com/22458241/190300352-6fad4437-9f2d-420d-8163-2832a452e285.png)

claunia commented

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

@dstanberry There's more details on that in https://github.com/microsoft/terminal/issues/6864#issuecomment-1246765956. I'm gonna collapse the rest of this as off-topic and move the discussion there.

@zadjii-msft commented on GitHub (Sep 15, 2022): @dstanberry There's more details on that in https://github.com/microsoft/terminal/issues/6864#issuecomment-1246765956. I'm gonna collapse the rest of this as off-topic and move the discussion there.

claunia commented

@nikkoaws commented on GitHub (Sep 17, 2022):

What testing is being done on the new Atlas Engine?

First thing I noticed after upgrading was the font rendering looks awful, and a quick side by side comparison of the previous and new renderer confirms this.

@nikkoaws commented on GitHub (Sep 17, 2022): What testing is being done on the new Atlas Engine? First thing I noticed after upgrading was the font rendering looks awful, and a quick side by side comparison of the previous and new renderer confirms this.

claunia commented

@DHowett commented on GitHub (Sep 17, 2022):

What testing is being done on the new Atlas Engine?

We are rolling it out in Preview to get some user feedback. This came only after we moved several hundred internal folks over to the atlas engine as a test.

I'd love to know what font you're using, at what size, and how it looks awful! Would you mind sharing?

@DHowett commented on GitHub (Sep 17, 2022): > What testing is being done on the new Atlas Engine? We are rolling it out in Preview to get some user feedback. This came only after we moved several hundred internal folks over to the atlas engine as a test. I'd love to know what font you're using, at what size, and how it looks awful! Would you mind sharing?

claunia commented

@BlackHoleFox commented on GitHub (Sep 18, 2022):

This is the closest existing issue I found but feel free to point me somewhere else. I started Windows Terminal yesterday and noticed that everything looked much thicker. A quick before/after with AtlasEngine enabled and disabled shows that its making all the text much thicker, changing sizing, and also what looks like shifting the positioning for some characters.

Version: Windows Terminal Preview 1.16.2523.0
Font size: 12pt
Font weight: Normal
Font face: CaskaydiaCove Nerd Font Mono

AtlasEngine disabled:

AtlasEngine enabled:

@BlackHoleFox commented on GitHub (Sep 18, 2022): This is the closest existing issue I found but feel free to point me somewhere else. I started Windows Terminal yesterday and noticed that everything looked much thicker. A quick before/after with AtlasEngine enabled and disabled shows that its making all the text much thicker, changing sizing, and also what looks like shifting the positioning for some characters. - Version: Windows Terminal Preview 1.16.2523.0 - Font size: 12pt - Font weight: Normal - Font face: [CaskaydiaCove Nerd Font Mono](https://github.com/ryanoasis/nerd-fonts/releases/download/v2.2.2/CascadiaCode.zip) AtlasEngine disabled: ![render_old](https://user-images.githubusercontent.com/20936452/190883466-c837392b-939d-4e73-b7fe-dc2c97c1a867.PNG) ![render_letters_old](https://user-images.githubusercontent.com/20936452/190883624-c6d30d7e-9150-4507-86dc-a6dfedbbfb65.PNG) AtlasEngine enabled: ![render_new](https://user-images.githubusercontent.com/20936452/190883470-22d8a41a-31e7-4e48-bfca-c928e96994a7.PNG) ![render_letters_new](https://user-images.githubusercontent.com/20936452/190883629-11d498e0-76aa-4e83-a61d-5a151ac580f5.PNG)

claunia commented

@nikkoaws commented on GitHub (Sep 19, 2022):

What testing is being done on the new Atlas Engine?

We are rolling it out in Preview to get some user feedback. This came only after we moved several hundred internal folks over to the atlas engine as a test.

I'd love to know what font you're using, at what size, and how it looks awful! Would you mind sharing?

Sure, below are some screen shots comparing the renderers, in particular the "a" and "e" highlight the weird rendering I am seeing.

The font is "Ubuntu Mono derivative Powerline", size: 14

@nikkoaws commented on GitHub (Sep 19, 2022): > > What testing is being done on the new Atlas Engine? > > We are rolling it out in Preview to get some user feedback. This came only after we moved several hundred internal folks over to the atlas engine as a test. > > I'd love to know what font you're using, at what size, and how it looks awful! Would you mind sharing? Sure, below are some screen shots comparing the renderers, in particular the "a" and "e" highlight the weird rendering I am seeing. The font is "Ubuntu Mono derivative Powerline", size: 14 ![new_renderer](https://user-images.githubusercontent.com/68265852/190986095-1d44eb52-4702-4715-8c86-722dc75def3d.png) ![old_renderer](https://user-images.githubusercontent.com/68265852/190986157-d278ad77-07a9-480f-91e6-32e060c8887c.png)

claunia commented

$atlas_engine_fractional_font_size$

@lhecker commented on GitHub (Sep 19, 2022):

@BlackHoleFox The old text renderer ("DxEngine") first computes the closest cell size using the given font size and then computes the actual font size based on the cell size. In your case the old engine has rounded down the cell size, resulting in an actual font size of 11.519999775pt. The new engine uses 12pt, just like you specified. Now that #14013 has merged you'll soon be able to specify 11.519999775 for the font size and it'll look exactly like it used to once again (apart from a slightly more compact line height):

@nikkoaws Your problem is basically the exact same. In your case the old engine has rounded down the cell size as well, resulting in an actual font size of 13.5pt. I'd suggest using either 13pt in the (looks identical to 13.5pt but with smaller line height), or disabling AtlasEngine in the meantime. The fractional font size support will likely arrive in 1.16 fairly soon.

BTW I made the change to not round the font size anymore, because I felt like if a user specifies a font size they should get that exact font size. Additionally it fixes some fairly severe blurriness issues for some other fonts.

@lhecker commented on GitHub (Sep 19, 2022): @BlackHoleFox The old text renderer ("DxEngine") first computes the closest cell size using the given font size and then computes the actual font size based on the cell size. In your case the old engine has rounded down the cell size, resulting in an actual font size of 11.519999775pt. The new engine uses 12pt, just like you specified. Now that #14013 has merged you'll soon be able to specify `11.519999775` for the font size and it'll look exactly like it used to once again (apart from a slightly more compact line height): ![atlas_engine_fractional_font_size](https://user-images.githubusercontent.com/2256941/191012388-78e058f7-c476-4dc5-86e0-b8ea04f149b8.gif) --- @nikkoaws Your problem is basically the exact same. In your case the old engine has rounded down the cell size as well, resulting in an actual font size of 13.5pt. I'd suggest using either 13pt in the (looks identical to 13.5pt but with smaller line height), or disabling AtlasEngine in the meantime. The fractional font size support will likely arrive in 1.16 fairly soon. BTW I made the change to not round the font size anymore, because I felt like if a user specifies a font size they should get that exact font size. Additionally it fixes some fairly severe blurriness issues for some other fonts.

claunia commented

@DHowett commented on GitHub (Sep 19, 2022):

In your case the old engine has rounded down the cell size, resulting in an actual font size of 11.519999775pt. The new engine uses 12pt, just like you specified.

I'm a little bit worried about this. I don't think that we can (with straight faces!) tell users to go edit their settings files to set a font size of 11.519999775 if they liked the old text rendering. If this truly is 12 point text, and Atlas is rendering it properly as 12 points... that suggests that the font is quite terribly broken.

At the same time, many fonts come with hinting information for point sizes ~8 - 12 (at 96 dpi). Rendering them correctly may result in crisper lines and slight, but intended, changes in letter forms to better accommodate lower resolution displays. If "CaskaydiaCove" has removed this hinting information, it could very well explain why it looks worse at 12.

@DHowett commented on GitHub (Sep 19, 2022): > In your case the old engine has rounded down the cell size, resulting in an actual font size of 11.519999775pt. The new engine uses 12pt, just like you specified. I'm a little bit worried about this. I don't think that we can (with straight faces!) tell users to go edit their settings files to set a font size of `11.519999775` if they liked the old text rendering. If this truly is _12 point text_, and Atlas is rendering it properly _as 12 points_... that suggests that the font is quite terribly broken. At the same time, many fonts come with hinting information for point sizes `~8 - 12` (at 96 dpi). Rendering them _correctly_ may result in crisper lines and slight, but intended, changes in letter forms to better accommodate lower resolution displays. If "CaskaydiaCove" has removed this hinting information, it could very well explain why it looks _worse_ at 12.

claunia commented

@lhecker commented on GitHub (Sep 19, 2022):

If this truly is 12 point text, and Atlas is rendering it properly as 12 points... that suggests that the font is quite terribly broken.

It's not that the font is broken, but rather that:

(Caskaydia Cove) Larger font sizes are mistaken for "heavier" text, as opposed to simply larger text.
This is supported by the fact that every report we've gotten for this was on low DPI, 100% scale displays, where this issue is more pronounced (since there's less pixels to snap to).
(Ubuntu Mono) Due to DxEngine rounding a given 14pt to 13.5pt, it actually effectively rendered text at 13pt, which allowed hinting to kick in, while it won't do that at 14pt.

In short, I believe we'll simply have to tell users that they need to edit their settings file to get the old behavior back, because the existing DxEngine behavior is just untenable unfortunately. 😔
The previous behavior made font sizes behave inconsistent and unpredictable, and sometimes certain font features outright impossible to use. For instance the pure bitmap font "Terminus TTF" was practically impossible to use on my 150% scale display initially, because certain font sizes simply didn't map to the correct bitmap size at all using DxEngine.

@lhecker commented on GitHub (Sep 19, 2022): > If this truly is 12 point text, and Atlas is rendering it properly as 12 _points_... that suggests that the font is quite terribly broken. It's not that the font is broken, but rather that: * (Caskaydia Cove) Larger font sizes are mistaken for "heavier" text, as opposed to simply larger text. This is supported by the fact that _every_ report we've gotten for this was on low DPI, 100% scale displays, where this issue is more pronounced (since there's less pixels to snap to). * (Ubuntu Mono) Due to DxEngine rounding a given 14pt to 13.5pt, it actually effectively rendered text at 13pt, which allowed hinting to kick in, while it won't do that at 14pt. In short, I believe we'll simply have to tell users that they need to edit their settings file to get the old behavior back, because the existing DxEngine behavior is just untenable unfortunately. 😔 The previous behavior made font sizes behave inconsistent and unpredictable, and sometimes certain font features outright impossible to use. For instance the pure bitmap font "Terminus TTF" was practically impossible to use on my 150% scale display initially, because certain font sizes simply didn't map to the correct bitmap size at all using DxEngine.

claunia commented

@nikkoaws commented on GitHub (Sep 20, 2022):

In short, I believe we'll simply have to tell users that they need to edit their settings file to get the old behavior back

@lhecker I'm not sure how viable it is, but ideally in the "Font size" section of settings it would be nice to place a warning that the current font size does not support hinting, and suggest the next nearest smaller and bigger font size that will render nicely.

@nikkoaws commented on GitHub (Sep 20, 2022): > In short, I believe we'll simply have to tell users that they need to edit their settings file to get the old behavior back @lhecker I'm not sure how viable it is, but ideally in the "Font size" section of settings it would be nice to place a warning that the current font size does not support hinting, and suggest the next nearest smaller and bigger font size that will render nicely.

claunia commented

@FWest98 commented on GitHub (Sep 20, 2022):

I have the same thing for me with any variant of the Cascadia font (not just the edited Nerd Font but also 'pure' Mono/Code). Indeed, the letters are (vertically) bigger in Atlas, and it causes the entire font to have a completely different feel. The strange thing is that the old feel matched very well with how the font feels in other tools like VS Code, Visual Studio 2022, Notepad, etc; while the new rendering feels very out-of-place compared to the other tools.

Do all tools do this font rendering wrong then?

@FWest98 commented on GitHub (Sep 20, 2022): I have the same thing for me with any variant of the Cascadia font (not just the edited Nerd Font but also 'pure' Mono/Code). Indeed, the letters are (vertically) bigger in Atlas, and it causes the entire font to have a completely different feel. The strange thing is that the old feel matched very well with how the font feels in other tools like VS Code, Visual Studio 2022, Notepad, etc; while the new rendering feels very out-of-place compared to the other tools. Do all tools do this font rendering wrong then?

claunia commented

@lhecker commented on GitHub (Sep 21, 2022):

The strange thing is that the old feel matched very well with how the font feels in other tools like VS Code, Visual Studio 2022, Notepad, etc; while the new rendering feels very out-of-place compared to the other tools.

If that's true, then I think we need to revert my change. While I think a given 12pt should be rendered as 12pt and not as "11.8938523pt" or something, I think that it's better to be consistent.

But... I can't speak of every editor you listed, but VS Code for instance configures its font size in CSS pixels (px = 96 DPI), whereas our setting uses CSS points (pt = 72 DPI). VS Code's default 14px font size maps to 10.5pt in Windows Terminal, which is something you can't actually configure. If it ever looked similar it was just by sheer coincidence and would break on any other display scale if you'd tried.

Edge and Chrome use the approximately same text rendering stack we use: DirectWrite/Direct2D, which is also used in most other Windows applications. But it's not the same text renderer as Visual Studio which uses WPF, which has its own text rendering algorithm. In either case, here's a comparison with Edge at 100% scale, 12pt Cascadia Code:

The only difference is in the glyph advance (= the spacing between the characters), which is because Edge/Chrome use a technique called "subpixel text positioning". If you're curious about it, here's a good overview that I read just earlier today.
This is something we should 100% also support in the future, but I don't think we're in a position to do that just yet. It makes performance optimizations harder and requires a number of refactorings around our cursor handling, etc.

But clearly the line height and x-height, as well as the overall look of the characters are identical. VS Code produces the exact same result as Edge, but with a larger/custom default line height of 1.4.

In other words, I at least can't reproduce any unexpected differences between us and VS Code, nor Chrome and it's derivatives, which makes me certain that we do at least something right...

@lhecker commented on GitHub (Sep 21, 2022): > The strange thing is that the old feel matched very well with how the font feels in other tools like VS Code, Visual Studio 2022, Notepad, etc; while the new rendering feels very out-of-place compared to the other tools. If that's true, then I think we need to revert my change. While I think a given 12pt should be rendered as 12pt and not as "11.8938523pt" or something, I think that it's better to be consistent. But... I can't speak of every editor you listed, but VS Code for instance configures its font size in CSS pixels (`px` = 96 DPI), whereas our setting uses CSS points (`pt` = 72 DPI). VS Code's default 14px font size maps to 10.5pt in Windows Terminal, which is something you can't actually configure. If it ever looked similar it was just by sheer coincidence and would break on any other display scale if you'd tried. Edge and Chrome use the approximately same text rendering stack we use: DirectWrite/Direct2D, which is also used in most other Windows applications. But it's _not_ the same text renderer as Visual Studio which uses WPF, which has its own text rendering algorithm. In either case, here's a comparison with Edge at 100% scale, 12pt Cascadia Code: ![atlas_engine_edge](https://user-images.githubusercontent.com/2256941/191384905-f3a862e4-69ec-4e45-b9cd-6e8f8515ef68.gif) The only difference is in the glyph advance (= the spacing between the characters), which is because Edge/Chrome use a technique called "subpixel text positioning". If you're curious about it, [here's a good overview that I read just earlier today](https://docs.google.com/document/d/1wpzgGMqXgit6FBVaO76epnnFC_rQPdVKswrDQWyqO1M/mobilebasic). This is something we should 100% also support in the future, but I don't think we're in a position to do that just yet. It makes performance optimizations harder and requires a number of refactorings around our cursor handling, etc. But clearly the line height and x-height, as well as the overall look of the characters are identical. VS Code produces the exact same result as Edge, but with a larger/custom default line height of 1.4. In other words, I at least can't reproduce any unexpected differences between us and VS Code, nor Chrome and it's derivatives, which makes me certain that we do at least something right...

claunia commented

@FWest98 commented on GitHub (Sep 21, 2022):

I took some time to collect some samples of the same content:
Font Renderings.zip

This includes old Windows CMD, Firefox, VS Code (and its terminal), and old/new WT behaviour. To me, the old WT and all other renderings all have in common that Cascadia Code appears as a "friendly" and "soft" font, with clear character separation. The old WT was already standing out a bit with a slightly "wider" and "softer" rendering.

To me, the Atlas renderer changes the impression of the font to a more "stern"/"serious" one. The character separation of e.g. the MM combinations is much less clear: in general the characters seem less well-separated. This too gives the impression of the font being "bolder", with higher weight. The glyph cell size stays constant, but the glyph seems to be "stretched" more with less margin - less than the other tools included in the zip. This is especially visible when you zoom in on the pixels of these characters in both renderers:

This might all be an unfortunate consequence of the specific font size ('12') and font and DPI (100%), but to me, it has quite a significant impact. More clever subpixel rendering might alleviate the issue a bit - from my sample WT is the only one without the clever subpixel rendering.

Another, more concrete thing is that glyphs are rendered differently between the two renderers, with a 'vertical-middle dot' being no longer in the middle as a noticeable issue (left-hand is Atlas). The size difference between glyphs in both versions is also big.

@FWest98 commented on GitHub (Sep 21, 2022): I took some time to collect some samples of the same content: [Font Renderings.zip](https://github.com/microsoft/terminal/files/9619873/Font.Renderings.zip) This includes old Windows CMD, Firefox, VS Code (and its terminal), and old/new WT behaviour. To me, the old WT and all other renderings all have in common that Cascadia Code appears as a "friendly" and "soft" font, with clear character separation. The old WT was already standing out a bit with a slightly "wider" and "softer" rendering. To me, the Atlas renderer changes the impression of the font to a more "stern"/"serious" one. The character separation of e.g. the `MM` combinations is much less clear: in general the characters seem less well-separated. This too gives the impression of the font being "bolder", with higher weight. The glyph cell size stays constant, but the glyph seems to be "stretched" more with less margin - less than the other tools included in the zip. This is especially visible when you zoom in on the pixels of these characters in both renderers: ![pixels](https://user-images.githubusercontent.com/1918658/191598648-ce5b3aa0-e597-4d6a-bff8-9680c1033381.gif) This might all be an unfortunate consequence of the specific font size ('12') and font and DPI (100%), but to me, it has quite a significant impact. More clever subpixel rendering might alleviate the issue a bit - from my sample WT is the only one without the clever subpixel rendering. Another, more concrete thing is that glyphs are rendered differently between the two renderers, with a 'vertical-middle dot' being no longer in the middle as a noticeable issue (left-hand is Atlas). The size difference between glyphs in both versions is also big. ![WT Glpyhs Comparison 2](https://user-images.githubusercontent.com/1918658/191599127-6fccaf28-495b-4099-92ee-e36324bd283b.png)

claunia commented

@DHowett commented on GitHub (Sep 21, 2022):

There's definitely something to this. I direct-compared notepad and Terminal at the same font size (8pt at 150% scale, which should map to 12 at 100), and my initial thought was that we looked thicker because we were using grayscale AA instead of subpixel. On closer inspection, though, it looks like it's something else. Even with subpixel rendering, there's a difference in what I think is hinting.

@DHowett commented on GitHub (Sep 21, 2022): There's definitely something to this. I direct-compared notepad and Terminal at the same font size (8pt at 150% scale, which should map to 12 at 100), and my initial thought was that we looked thicker because we were using grayscale AA instead of subpixel. On closer inspection, though, it looks like it's something else. Even with subpixel rendering, there's a difference in what I think is _hinting_. ![this_was_so_frustratingly_difficult_to_make](https://user-images.githubusercontent.com/189190/191609587-3b0db4f2-945b-4475-b1a8-5250e06e12d7.gif)

claunia commented