starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-23 23:45:08 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

experimental.useAtlasEngine breaks draw-box rendering #16799

New Issue
Closed
opened 2026-01-31 05:23:06 +00:00 by claunia · 17 comments
claunia commented 2026-01-31 05:23:06 +00:00
Owner
Copy Link

Originally created by @237dmitry on GitHub (Feb 17, 2022).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

1.13.10336.0

Windows build number

10.0.22000.0

Other Software

Any application which uses pseudo graphics.

Steps to reproduce

Enable this feature and restart Terminal. Open any program which uses pseudo graphics. Far, Musikcube etc.

Expected Behavior

There should be no distortion

Actual Behavior

ss-1

ss-2

Originally created by @237dmitry on GitHub (Feb 17, 2022). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version 1.13.10336.0 ### Windows build number 10.0.22000.0 ### Other Software Any application which uses pseudo graphics. ### Steps to reproduce Enable this feature and restart Terminal. Open any program which uses pseudo graphics. Far, Musikcube etc. ### Expected Behavior There should be no distortion ### Actual Behavior ![ss-1](https://user-images.githubusercontent.com/78153320/154446002-55733a76-76fb-4767-a748-f1d4daecf011.png) ![ss-2](https://user-images.githubusercontent.com/78153320/154447231-7651a0aa-15a0-441d-92a5-66b950fdea23.png)
claunia commented 2026-01-31 05:23:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 17, 2022):

See also #455 which did this for the dx engine, and make sure we don't regress #6974 (which seems fixed in atlas right now)

@zadjii-msft commented on GitHub (Feb 17, 2022): See also #455 which did this for the dx engine, and make sure we don't regress #6974 (which seems fixed in atlas right now)
claunia commented 2026-01-31 05:23:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 18, 2022):

Just to give a brief technical explanation apart from "we simply haven't tested box drawing characters in AtlasEngine yet":
Those gaps exist, because we use the size of your chosen font to calculate the grid size of your terminal. Cascadia Code at 12pt results in a grid of 15px by 30px at 150% display scale. Box drawing characters however come from some fallback font, which doesn't necessarily have the same "idea" of how large that cell is and so your box character might only be 14.5px by 29px.

If you use the right font and play with Ctrl+Scrollwheel you get this:
image

(And it's the reason why only #455 is a proper solution.)

@lhecker commented on GitHub (Feb 18, 2022): Just to give a brief technical explanation apart from "we simply haven't tested box drawing characters in AtlasEngine yet": Those gaps exist, because we use the size of your chosen font to calculate the grid size of your terminal. Cascadia Code at 12pt results in a grid of 15px by 30px at 150% display scale. Box drawing characters however come from some fallback font, which doesn't necessarily have the same "idea" of how large that cell is and so your box character might only be 14.5px by 29px. If you use the right font and play with Ctrl+Scrollwheel you get this: ![image](https://user-images.githubusercontent.com/2256941/154598653-b75a8a04-cc46-49f5-a14c-dd3b462fcdd8.png) (And it's the reason why only #455 is a proper solution.)
claunia commented 2026-01-31 05:23:08 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Feb 18, 2022):

If you use the right font and play with Ctrl+Scrollwheel you get this:

You must be joking. Right font, right size.... Right display scaling, 150% !!!!! This is an experimental feature. I just pointed out its shortcomings.

ss

@237dmitry commented on GitHub (Feb 18, 2022): > If you use the right font and play with Ctrl+Scrollwheel you get this: You must be joking. Right font, right size.... Right display scaling, 150% !!!!! This is an experimental feature. I just pointed out its shortcomings. ![ss](https://user-images.githubusercontent.com/78153320/154628816-e30099a2-f8ec-43fe-9b69-7fc17bca00f7.png)
claunia commented 2026-01-31 05:23:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 18, 2022):

You must be joking. Right font, right size.... Right display scaling, 150% !!!!! This is an experimental feature. I just pointed out its shortcomings.

I'm sorry, I believe this is due to our language barrier since I'm not a native English speaker.
What I tried to express was a "technical explanation", not an excuse why it should stay that way. The screenshot is just a demonstration for that effect.

The experimental text rendering engine will have its shortcomings fixed as soon as I can. 🙂

@lhecker commented on GitHub (Feb 18, 2022): > You must be joking. Right font, right size.... Right display scaling, 150% !!!!! This is an experimental feature. I just pointed out its shortcomings. I'm sorry, I believe this is due to our language barrier since I'm not a native English speaker. What I tried to express was a "technical explanation", not an excuse why it should stay that way. The screenshot is just a demonstration for that effect. The experimental text rendering engine will have its shortcomings fixed as soon as I can. 🙂
claunia commented 2026-01-31 05:23:08 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Feb 18, 2022):

I'm sorry, I believe this is due to our language barrier since I'm not a native English speaker.

I'm sorry too )) I used online translator. I could not change font weight with Ctrl+Mouse in TUI.

What is this engine for? You are trying to make the application beautiful and responsive, but at the same time in editors that have automatic indentation enabled, the text inserted from the clipboard moves to the right by the amount of the sum of its own indentation and the indentation of the previous line.

micro

https://user-images.githubusercontent.com/78153320/154696143-afaa2215-b76a-43f3-816f-2a029ec9466c.mp4

@237dmitry commented on GitHub (Feb 18, 2022): > I'm sorry, I believe this is due to our language barrier since I'm not a native English speaker. I'm sorry too )) I used online translator. I could not change font weight with Ctrl+Mouse in TUI. What is this engine for? You are trying to make the application beautiful and responsive, but at the same time in editors that have automatic indentation enabled, the text inserted from the clipboard moves to the right by the amount of the sum of its own indentation and the indentation of the previous line. ![micro](https://user-images.githubusercontent.com/78153320/152793238-a343f205-5ed1-49cc-9164-ca9e9b8a2fa1.png) https://user-images.githubusercontent.com/78153320/154696143-afaa2215-b76a-43f3-816f-2a029ec9466c.mp4
claunia commented 2026-01-31 05:23:09 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 18, 2022):

I'm sorry too )) I used online translator.

In case you're speaking Russian, I can translate my comments for you.

What is this engine for?

The "experimental rendering engine" will be the default engine in the future. Here you can see how much faster it is for box character drawings:

https://user-images.githubusercontent.com/2256941/152468973-f554c8c5-5ca0-4953-93e0-db15142fe59d.mp4

You are trying to make the application beautiful and responsive, but at the same time in editors that have automatic indentation enabled, the text inserted from the clipboard moves to the right by the amount of the sum of its own indentation and the indentation of the previous line.

You're talking about #12411, right? The reason this happens is because Windows added support for escape sequences only very recently. Many applications still use "hacky" solutions to implement support for clipboards and other things. This is the likely reason why "micro" indents your clipboard incorrectly. And it's the likely reason why it works under WSL, because WSL forces you to use escape sequences.
In short: When an application works under WSL, but doesn't work under Windows natively, it's usually a bug in the application ("micro" for instance).

@lhecker commented on GitHub (Feb 18, 2022): > I'm sorry too )) I used online translator. In case you're speaking Russian, I can translate my comments for you. > What is this engine for? The "experimental rendering engine" will be the default engine in the future. Here you can see how much faster it is for box character drawings: https://user-images.githubusercontent.com/2256941/152468973-f554c8c5-5ca0-4953-93e0-db15142fe59d.mp4 > You are trying to make the application beautiful and responsive, but at the same time in editors that have automatic indentation enabled, the text inserted from the clipboard moves to the right by the amount of the sum of its own indentation and the indentation of the previous line. You're talking about #12411, right? The reason this happens is because Windows added support for escape sequences only very recently. Many applications still use "hacky" solutions to implement support for clipboards and other things. This is the likely reason why "micro" indents your clipboard incorrectly. And it's the likely reason why it works under WSL, because WSL forces you to use escape sequences. In short: When an application works under WSL, but doesn't work under Windows natively, it's usually a bug in the application ("micro" for instance).
claunia commented 2026-01-31 05:23:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 18, 2022):

(To try and keep things on topic, I'm gonna minimize and hide the discussion about the indenting. We can continue that discussion over in #12411.)

@zadjii-msft commented on GitHub (Feb 18, 2022): (To try and keep things on topic, I'm gonna minimize and hide the discussion about the indenting. We can continue that discussion over in #12411.)
claunia commented 2026-01-31 05:23:10 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Feb 18, 2022):

Sorry for indent-offtop. It's just infuriating.

The "experimental rendering engine" will be the default engine in the future.

Does this mean that if this engine becomes the default, that it will be the only engine? Atlas works three times faster, it's true. But before it is approved, I hope that it will be thoroughly tested and this small but unpleasant bug will be fixed.

@237dmitry commented on GitHub (Feb 18, 2022): Sorry for indent-offtop. It's just infuriating. > The "experimental rendering engine" will be the default engine in the future. Does this mean that if this engine becomes the default, that it will be the only engine? Atlas works three times faster, it's true. But before it is approved, I hope that it will be thoroughly tested and this small but unpleasant bug will be fixed.
claunia commented 2026-01-31 05:23:10 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 18, 2022):

Does this mean that if this engine becomes the default, that it will be the only engine? Atlas works three times faster, it's true. But before it is approved, I hope that it will be thoroughly tested and this small but unpleasant bug will be fixed.

We'll probably always retain the DxEngine (the current one) as a fall back. Don't worry, we've still got a long list of bugs to sort out: #9999. Plus, three times faster is not nearly fast enough 🤣

@zadjii-msft commented on GitHub (Feb 18, 2022): > Does this mean that if this engine becomes the default, that it will be the only engine? Atlas works three times faster, it's true. But before it is approved, I hope that it will be thoroughly tested and this small but unpleasant bug will be fixed. We'll probably always retain the DxEngine (the current one) as a fall back. Don't worry, we've still got a long list of bugs to sort out: #9999. Plus, three times faster is not nearly fast enough 🤣
claunia commented 2026-01-31 05:23:10 +00:00
Author
Owner
Copy Link

@brwilkinson commented on GitHub (Feb 18, 2022):

Adding a comment on strange rendering of ansi/Unicode?

            {
                "commandline": "C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe -NoLogo",
                "elevate": true,
                "experimental.useAtlasEngine": true,  // rendering icons breaks
                "guid": "{a3a2e83a-884a-5379-baa8-16f193a13b21}",
                "hidden": false,
                "name": "PowerShell 7 Preview",
                "source": "Windows.Terminal.PowershellCore"
            }

Testing out "experimental.useAtlasEngine": true

I get the following:

image

setting to false

image

referencing other thread as well: https://github.com/microsoft/terminal/issues/9999

@brwilkinson commented on GitHub (Feb 18, 2022): Adding a comment on strange rendering of ansi/Unicode? ```json { "commandline": "C:\\Program Files\\PowerShell\\7-preview\\pwsh.exe -NoLogo", "elevate": true, "experimental.useAtlasEngine": true, // rendering icons breaks "guid": "{a3a2e83a-884a-5379-baa8-16f193a13b21}", "hidden": false, "name": "PowerShell 7 Preview", "source": "Windows.Terminal.PowershellCore" } ``` Testing out `"experimental.useAtlasEngine": true` I get the following: ![image](https://user-images.githubusercontent.com/3605266/154771456-9913b492-8911-44da-9658-37b0b5bf9db1.png) setting to false ![image](https://user-images.githubusercontent.com/3605266/154771510-799caba1-693c-4451-959e-9573bbb8a887.png) referencing other thread as well: https://github.com/microsoft/terminal/issues/9999
claunia commented 2026-01-31 05:23:11 +00:00
Author
Owner
Copy Link

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

@brwilkinson That's a separate issue. I'll add it to the list in #9999.
It's basically the inverse of #3546. There's no real standard spec for how wide characters are treated in terminals. Some terminals will draw glyphs in their designed size, no matter what comes after the wide glyph.
In your screenshot for instance you have an unicode character representing GitHub, followed by whitespace. The whitespace is there to ensure that terminals like the current standard renderer, or Apple's Terminal have enough space to draw that wide glyph, even though your custom GitHub icon should actually be a narrow glyph according to Unicode.

So the solution here is to be ""incorrect"" as well and simply draw overly wide glyphs over anything that comes past them.

@lhecker commented on GitHub (Feb 19, 2022): @brwilkinson That's a separate issue. I'll add it to the list in #9999. It's basically the inverse of #3546. There's no real standard spec for how wide characters are treated in terminals. Some terminals will draw glyphs in their designed size, no matter what comes after the wide glyph. In your screenshot for instance you have an unicode character representing GitHub, followed by whitespace. The whitespace is there to ensure that terminals like the current standard renderer, or Apple's Terminal have enough space to draw that wide glyph, even though your custom GitHub icon should _actually_ be a narrow glyph according to Unicode. So the solution here is to be ""incorrect"" as well and simply draw overly wide glyphs over anything that comes past them.
claunia commented 2026-01-31 05:23:11 +00:00
Author
Owner
Copy Link

@brwilkinson commented on GitHub (Feb 19, 2022):

Thanks @lhecker sorry I should have used the other thread...

Oh right I just realized I wasn't actually using a monospaced font like I thought I was.

image

FiraCode NF is monospaced
FiraCode NerdFont is not

Mono
image

non Mono
image

@brwilkinson commented on GitHub (Feb 19, 2022): Thanks @lhecker sorry I should have used the other thread... Oh right I just realized I wasn't actually using a monospaced font like I thought I was. ![image](https://user-images.githubusercontent.com/3605266/154779125-e2655b43-5111-403b-a2f4-322aeacbcece.png) FiraCode NF is monospaced FiraCode NerdFont is not Mono ![image](https://user-images.githubusercontent.com/3605266/154779163-f36df652-5b95-4c95-96c9-f68f8533d304.png) non Mono ![image](https://user-images.githubusercontent.com/3605266/154779183-699a0321-5fc3-4141-a3ca-e154fec8e072.png)
claunia commented 2026-01-31 05:23:11 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Feb 19, 2022):

FiraCode NF is monospaced

First of all, NF fonts are outdated and will no longer be supported, and secondly, the characters for private use are half as small as in GitHub Nerd Fonts, which looks twice as bad.

@237dmitry commented on GitHub (Feb 19, 2022): > FiraCode NF is monospaced First of all, NF fonts are outdated and will no longer be supported, and secondly, the characters for private use are half as small as in [GitHub Nerd Fonts](https://github.com/ryanoasis/nerd-fonts), which looks twice as bad.
claunia commented 2026-01-31 05:23:12 +00:00
Author
Owner
Copy Link

@brwilkinson commented on GitHub (Feb 19, 2022):

First of all, NF fonts are outdated and will no longer be supported, and secondly, the characters for private use are half as small as in GitHub Nerd Fonts, which looks twice as bad.

hmmm I tried to get/update the Fira Code fonts from that side and they didn't seem to support glyphs?! Previously I had always downloaded from nerdfonts.com and ended up with the 'FiraCode NerdFont' only just in December when I updated I ended up with 'FiraCode NF' I don't actually know what changed, I believe I only got my fonts from Nerdfonts.com.

So now I assume that both sets of fonts were monospaced? it's just that the glyphs render at different sizes, I tried to add an extra space after the glyph, however the extra size did not overflow into the space, it was still cut off. I do agree the larger glyphs look nicer (if they were not cut off).

@brwilkinson commented on GitHub (Feb 19, 2022): > First of all, NF fonts are outdated and will no longer be supported, and secondly, the characters for private use are half as small as in [GitHub Nerd Fonts](https://github.com/ryanoasis/nerd-fonts), which looks twice as bad. hmmm I tried to get/update the Fira Code fonts from that side and they didn't seem to support glyphs?! Previously I had always downloaded from nerdfonts.com and ended up with the 'FiraCode NerdFont' only just in December when I updated I ended up with 'FiraCode NF' I don't actually know what changed, I believe I only got my fonts from Nerdfonts.com. So now I assume that both sets of fonts were monospaced? it's just that the glyphs render at different sizes, I tried to add an extra space after the glyph, however the extra size did not overflow into the space, it was still cut off. I do agree the larger glyphs look nicer (if they were not cut off).
claunia commented 2026-01-31 05:23:12 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Feb 19, 2022):

So now I assume that both sets of fonts were monospaced?

They both are monospaced. But Nerd Fonts fonts, unlike NF, have characters in their set, not only with single glyphs, but also with double ones. Some symbols, taking into account the preservation of the overall proportions, do not fit in one cell. The Atlas engine apparently does not know how to display such characters, it cuts one glyph off. Nerd Fonts are very widely used today, as they are perfectly rendered everywhere, even in conhost.exe .

@237dmitry commented on GitHub (Feb 19, 2022): > So now I assume that both sets of fonts were monospaced? They both are monospaced. But `Nerd Fonts` fonts, unlike `NF`, have characters in their set, not only with single glyphs, but also with double ones. Some symbols, taking into account the preservation of the overall proportions, do not fit in one cell. The Atlas engine apparently does not know how to display such characters, it cuts one glyph off. Nerd Fonts are very widely used today, as they are perfectly rendered everywhere, even in conhost.exe .
claunia commented 2026-01-31 05:23:12 +00:00
Author
Owner
Copy Link

@jessey-git commented on GitHub (May 11, 2022):

I may be encountering the same issue when using Atlas (experimental) but I don't understand the nuances around different fonts to know for sure. Is the following screen indicative of this issue here?

Using "MesloLGM NF" size 9 -- issues with character U+E0B0 on the left side here:
atlas-issue

@jessey-git commented on GitHub (May 11, 2022): I may be encountering the same issue when using Atlas (experimental) but I don't understand the nuances around different fonts to know for sure. Is the following screen indicative of this issue here? Using "MesloLGM NF" size 9 -- issues with character U+E0B0 on the left side here: ![atlas-issue](https://user-images.githubusercontent.com/7989986/167742215-595ada7f-4638-4ce2-884e-50b316f3f9fd.png)
claunia commented 2026-01-31 05:23:12 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 13, 2022):

:tada:This issue was addressed in #13549, which has now been successfully released as Windows Terminal Preview v1.16.252.🎉

Handy links:

@ghost commented on GitHub (Sep 13, 2022): :tada:This issue was addressed in #13549, which has now been successfully released as `Windows Terminal Preview v1.16.252`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.16.252) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-AtlasEngine Issue-Bug Needs-Tag-Fix Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16799
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?