starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

AtlasEngine rendering wide Nerd Font glyphs incorrectly #18483

New Issue
Closed
opened 2026-01-31 06:15:28 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 06:15:28 +00:00
Owner
Copy Link

Originally created by @SivanagBalla on GitHub (Sep 16, 2022).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

1.16.2523.0

Windows build number

10.0.19044

Other Software

UbuntuMono Nerd font installed from https://github.com/ryanoasis/nerd-fonts/releases/download/v2.2.2/Ubuntu.zip
WSL, running Ubuntu 20.04.1 LTS. SSHing into a RHEL server
The linux server is running tmux with custom status bar with "double wide" icon characters

Steps to reproduce

Use UbuntuMono Nerd Font and configure some double wide character in status bar or print them in terminal

Issue is seen with new AtlasEngined enabled(which is default with new version). Disabling AtlasEngine will bring back old behaviour

Expected Behavior

Double wide characters such as clock, calender which are available in NerdFond are to be rendered as below

image
image

Actual Behavior

image
image

Originally created by @SivanagBalla on GitHub (Sep 16, 2022). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version 1.16.2523.0 ### Windows build number 10.0.19044 ### Other Software UbuntuMono Nerd font installed from https://github.com/ryanoasis/nerd-fonts/releases/download/v2.2.2/Ubuntu.zip WSL, running Ubuntu 20.04.1 LTS. SSHing into a RHEL server The linux server is running tmux with custom status bar with "double wide" icon characters ### Steps to reproduce Use UbuntuMono Nerd Font and configure some double wide character in status bar or print them in terminal Issue is seen with new AtlasEngined enabled(which is default with new version). Disabling AtlasEngine will bring back old behaviour ### Expected Behavior Double wide characters such as clock, calender which are available in NerdFond are to be rendered as below ![image](https://user-images.githubusercontent.com/19350704/190709997-35fe81c5-d140-4de1-b12a-ec1233cb8fc7.png) ![image](https://user-images.githubusercontent.com/19350704/190710041-609808cf-10d9-415c-8f35-3a46a0252df8.png) ### Actual Behavior ![image](https://user-images.githubusercontent.com/19350704/190710323-5d31dd7f-edd3-41f5-8028-57b81f607d6c.png) ![image](https://user-images.githubusercontent.com/19350704/190710363-7cd8eed9-ce04-472e-b560-f43020675edd.png)
claunia added the Issue-BugIn-PRProduct-TerminalPriority-2Area-AtlasEngine labels 2026-01-31 06:15:28 +00:00
claunia commented 2026-01-31 06:15:30 +00:00
Author
Owner
Copy Link

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

same here

@T4P4N commented on GitHub (Sep 17, 2022): same here
claunia commented 2026-01-31 06:15:30 +00:00
Author
Owner
Copy Link

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

I gave this issue a title that will hopefully make it easier to find in the future. 🙂

FYI I'm currently working on a version of AtlasEngine that solves this issue fundamentally, by going with a more traditional text rendering approach, allowing for freely overlapping glyphs. My prototype is already capable of handling all Nerd Font glyphs correctly.
Unfortunately however it comes with its own set of downsides (slightly slower, more complex, doesn't support user-defined text shaders), so the jury is still out on when and in what shape we'll fix this issue. Don't worry though: Until it's been fixed, the old text renderer will not go away.

@lhecker commented on GitHub (Sep 25, 2022): I gave this issue a title that will hopefully make it easier to find in the future. 🙂 FYI I'm currently working on a version of AtlasEngine that solves this issue fundamentally, by going with a more traditional text rendering approach, allowing for freely overlapping glyphs. My prototype is already capable of handling all Nerd Font glyphs correctly. Unfortunately however it comes with its own set of downsides (slightly slower, more complex, doesn't support user-defined text shaders), so the jury is still out on when and in what shape we'll fix this issue. Don't worry though: Until it's been fixed, the old text renderer will not go away.
claunia commented 2026-01-31 06:15:30 +00:00
Author
Owner
Copy Link

@stephc-int13 commented on GitHub (Sep 25, 2022):

I gave this issue a title that will hopefully make it easier to find in the future. 🙂

FYI I'm currently working on a version of AtlasEngine that solves this issue fundamentally, by going with a more traditional text rendering approach, allowing for freely overlapping glyphs. My prototype is already capable of handling all Nerd Font glyphs correctly. Unfortunately however it comes with its own set of downsides (slightly slower, more complex, doesn't support user-defined text shaders), so the jury is still out on when and in what shape we'll fix this issue. Don't worry though: Until it's been fixed, the old text renderer will not go away.

You could probably do that in two passes.
First pass with the usual shader rendering standard cells, second pass rendering the overlapping cells if necessary.
That is probably optimal and avoid unnecessary overhead.

@stephc-int13 commented on GitHub (Sep 25, 2022): > I gave this issue a title that will hopefully make it easier to find in the future. 🙂 > > FYI I'm currently working on a version of AtlasEngine that solves this issue fundamentally, by going with a more traditional text rendering approach, allowing for freely overlapping glyphs. My prototype is already capable of handling all Nerd Font glyphs correctly. Unfortunately however it comes with its own set of downsides (slightly slower, more complex, doesn't support user-defined text shaders), so the jury is still out on when and in what shape we'll fix this issue. Don't worry though: Until it's been fixed, the old text renderer will not go away. You could probably do that in two passes. First pass with the usual shader rendering standard cells, second pass rendering the overlapping cells if necessary. That is probably optimal and avoid unnecessary overhead.
claunia commented 2026-01-31 06:15:31 +00:00
Author
Owner
Copy Link

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

You could probably do that in two passes.
First pass with the usual shader rendering standard cells, second pass rendering the overlapping cells if necessary.
That is probably optimal and avoid unnecessary overhead.

That would mean I'd have to keep both, the complexity of our current approach and add the complexity of the new approach for fallback. That would probably make maintainability more difficult than a larger one time change. An idea I had to keep some of the current benefits was to just composite all text into a viewport-sized offscreen texture and blend it onto the swap chain in a single final shading pass, similar to how we do it now.
BTW to give some context on the "slightly slower" / overhead I mentioned: The new approach I've prototyped runs within my test setup at ~200us per frame, whereas the old one needs ~100us per frame. Sure, that's twice as slow, but I'm not even using instancing yet to render glyph quads (or Nvidia's QuadFillMode), nor are we anywhere close to the 500-1000us that the old renderer needs. 😅
I still got quite a number of kinks to iron out, but once that's done I'll discuss with everyone on the team how to best integrate such changes.

image

@lhecker commented on GitHub (Sep 25, 2022): > You could probably do that in two passes. > First pass with the usual shader rendering standard cells, second pass rendering the overlapping cells if necessary. > That is probably optimal and avoid unnecessary overhead. That would mean I'd have to keep both, the complexity of our current approach and add the complexity of the new approach for fallback. That would probably make maintainability more difficult than a larger one time change. An idea I had to keep some of the current benefits was to just composite all text into a viewport-sized offscreen texture and blend it onto the swap chain in a single final shading pass, similar to how we do it now. BTW to give some context on the "slightly slower" / overhead I mentioned: The new approach I've prototyped runs within my test setup at ~200us per frame, whereas the old one needs ~100us per frame. Sure, that's twice as slow, but I'm not even using instancing yet to render glyph quads (or Nvidia's `QuadFillMode`), nor are we anywhere close to the 500-1000us that the old renderer needs. 😅 I still got quite a number of kinks to iron out, but once that's done I'll discuss with everyone on the team how to best integrate such changes. ![image](https://user-images.githubusercontent.com/2256941/192153350-b024672d-ace7-4a14-ac23-47a70f7f096d.png)
claunia commented 2026-01-31 06:15:31 +00:00
Author
Owner
Copy Link

@stephc-int13 commented on GitHub (Sep 25, 2022):

I don't think you need to fall back on per glyph rendering to solve the special wide glyphs needed for proper nerdfont icons rendering.

I understand that the speed difference is not significant, IMHO your solution is more complex than doing two passes with shader on a quad.

First pass as already done. (Ignoring wider glyphs)
Second pass only on "special" glyphs with wider cells. ( with almost the same shader, not per glyph quads)

It might even be possible to do everything in a single pass shader, but that should be tested.

@stephc-int13 commented on GitHub (Sep 25, 2022): I don't think you need to fall back on per glyph rendering to solve the special wide glyphs needed for proper nerdfont icons rendering. I understand that the speed difference is not significant, IMHO your solution is more complex than doing two passes with shader on a quad. First pass as already done. (Ignoring wider glyphs) Second pass only on "special" glyphs with wider cells. ( with almost the same shader, not per glyph quads) It might even be possible to do everything in a single pass shader, but that should be tested.
claunia commented 2026-01-31 06:15:31 +00:00
Author
Owner
Copy Link

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

When we render we need to conceptually draw in "layers" from bottom to top and AtlasEngine did it in 1 pass:

  • 1st pass:
    • background color
    • selection (variant 1)
    • cursor (variant 1 and 2)
    • glyphs
    • text decorations (overline, underline, strikethrough, etc.)
    • sixels, etc.
    • selection (variant 2)

But in order to draw wide glyphs in between we can't draw in 2 passes. We need 3, since things like sixels or selections are "on top" of the lower contents. From what I can see it basically turns into:

  • 1st pass:
    • background color
    • selection (variant 1)
    • cursor (variant 1 and 2)
    • glyphs
    • † text decorations (overline, underline, strikethrough, etc.)
    • † sixels, etc.
    • † selection (variant 2)
  • 2nd pass (optional):
    • overly large glyphs (don't adhere to the cell grid)
    • sixels, etc.
  • 3rd pass ‡:
    • ‡ text decorations (overline, underline, strikethrough, etc.)
    • ‡ sixels, etc.
    • ‡ selection (variant 2)

† optional if no 2nd pass
‡ required if 2nd pass

This is my new approach:

  • 1st pass:
    • background color
    • selection (variant 1)
  • 2nd pass:
    • any glyphs
    • text decorations (overline, underline, strikethrough, etc.)
    • sixels, etc.
    • selection (variant 2)

Additionally it actually reduces the amount of code required for text rendering by ~12% (it's just that the remaining code requires more intimate knowledge about DirectWrite and Direct3D). And I think I even know how to merge both to draw them in just a single pass all the time. As such right now I personally don't agree that keeping both approaches simultaneously offers a strong benefit.
I'm open to any ideas how to not draw individual quads and I'd be happy to be convinced otherwise, but even if you're right that it's simpler and better, given my knowledge I just wouldn't know how that would work.

@lhecker commented on GitHub (Sep 25, 2022): When we render we need to conceptually draw in "layers" from bottom to top and AtlasEngine did it in 1 pass: * 1st pass: * background color * selection (variant 1) * cursor (variant 1 and 2) * glyphs * text decorations (overline, underline, strikethrough, etc.) * sixels, etc. * selection (variant 2) But in order to draw wide glyphs in between we can't draw in 2 passes. We need 3, since things like sixels or selections are "on top" of the lower contents. From what I can see it basically turns into: * 1st pass: * background color * selection (variant 1) * cursor (variant 1 and 2) * glyphs * † text decorations (overline, underline, strikethrough, etc.) * † sixels, etc. * † selection (variant 2) * 2nd pass (optional): * overly large glyphs (don't adhere to the cell grid) * sixels, etc. * 3rd pass ‡: * ‡ text decorations (overline, underline, strikethrough, etc.) * ‡ sixels, etc. * ‡ selection (variant 2) † optional if no 2nd pass ‡ required if 2nd pass This is my new approach: * 1st pass: * background color * selection (variant 1) * 2nd pass: * any glyphs * text decorations (overline, underline, strikethrough, etc.) * sixels, etc. * selection (variant 2) Additionally it actually reduces the amount of code required for text rendering by ~12% (it's just that the remaining code requires more intimate knowledge about DirectWrite and Direct3D). And I _think_ I even know how to merge both to draw them in just a single pass all the time. As such right now I personally don't agree that keeping both approaches simultaneously offers a strong benefit. I'm open to any ideas how to not draw individual quads and I'd be happy to be convinced otherwise, but even if you're right that it's simpler and better, given _my_ knowledge I just wouldn't know how that would work.
claunia commented 2026-01-31 06:15:32 +00:00
Author
Owner
Copy Link

@stephc-int13 commented on GitHub (Sep 25, 2022):

The more I think about it the more I think that the whole rendering can be entirely done in one single shader pass.

But that does require a bit of preprocessing and adding metadata for each cell to handle all the cases.
That would mostly be a few special case flags to tell the shader to look for more information in adjacent cells (top, left or bottom)

But of course, given that performance gains are not critical (the optimal solution would be a bit more power efficient) you should simply follow your guts and go for the solution that is the simpler to implement for you.

@stephc-int13 commented on GitHub (Sep 25, 2022): The more I think about it the more I think that the whole rendering can be entirely done in one single shader pass. But that does require a bit of preprocessing and adding metadata for each cell to handle all the cases. That would mostly be a few special case flags to tell the shader to look for more information in adjacent cells (top, left or bottom) But of course, given that performance gains are not critical (the optimal solution would be a bit more power efficient) you should simply follow your guts and go for the solution that is the simpler to implement _for you_.
claunia commented 2026-01-31 06:15:32 +00:00
Author
Owner
Copy Link

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

Thanks for your input! I'll definitely try my hardest to come up with something decent. Nothing is set in stone so far. 🙂

@lhecker commented on GitHub (Sep 25, 2022): Thanks for your input! I'll definitely try my hardest to come up with something decent. Nothing is set in stone so far. 🙂
claunia commented 2026-01-31 06:15:32 +00:00
Author
Owner
Copy Link

@jessey-git commented on GitHub (Sep 27, 2022):

I seem to have a similar problem, except that version 2523 is ok, but the most recent 2642 is broken. I'm using MesloLGM NF at size 9.0 (tried 8.5 and 9.5 as well and those were much worse).

2523 on top, 2642 on bottom:
fontbrokenness

Is this the same or a different issue?

@jessey-git commented on GitHub (Sep 27, 2022): I seem to have a similar problem, except that version 2523 is ok, but the most recent 2642 is broken. I'm using MesloLGM NF at size 9.0 (tried 8.5 and 9.5 as well and those were much worse). 2523 on top, 2642 on bottom: ![fontbrokenness](https://user-images.githubusercontent.com/7989986/192405105-9fd1c813-71e5-4e54-a91a-58dc642236c4.png) Is this the same or a different issue?
claunia commented 2026-01-31 06:15:33 +00:00
Author
Owner
Copy Link

@stephc-int13 commented on GitHub (Sep 27, 2022):

You can disable the new atlas renderer in the settings, if that solves your issue then it is related.

@stephc-int13 commented on GitHub (Sep 27, 2022): You can disable the new atlas renderer in the settings, if that solves your issue then it is related.
claunia commented 2026-01-31 06:15:33 +00:00
Author
Owner
Copy Link

@jessey-git commented on GitHub (Sep 27, 2022):

Yeah, disabling Atlas fixes the problem. Welp, it worked for almost 14 days with the prior version. It had a good run :) Will try Atlas again once this issue here is all fixed.

@jessey-git commented on GitHub (Sep 27, 2022): Yeah, disabling Atlas fixes the problem. Welp, it worked for almost 14 days with the prior version. It had a good run :) Will try Atlas again once this issue here is all fixed.
claunia commented 2026-01-31 06:15:34 +00:00
Author
Owner
Copy Link

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

@jessey-git I'm sorry I broke your font! 😔

I hope you don't mind me saying this, but your font is... weird. 😄
It looks beautiful of course, but it handles its block characters in a very unusual manner. That character (U+E0B0) works in all other Nerd Fonts I got installed (for instance Fira Code), just not with this Meslo variant, which is already a bit weird. Additionally my understanding is that block characters are expected to have approximately the same size as the font's advance width and height. While most Nerd Fonts variants are slightly incorrect in that regard, Meslo in particular is really bad about this. This particular glyph for instance is almost 40% taller than the advance height it specifies which causes it to look like that. The only difference between build 2523 and 2642 is how those glyphs are vertically centered. In both screenshots you're missing more than half of that glyph - it's actually supposed to be a perfect triangle like this:
image

Basically, IMO Nerd Fonts should stop making block glyphs taller than the font's advance height.
In either case I'm going to simply revert the change that causes your issues: #14085

@lhecker commented on GitHub (Sep 27, 2022): @jessey-git I'm sorry I broke your font! 😔 I hope you don't mind me saying this, but your font is... weird. 😄 It looks beautiful of course, but it handles its block characters in a very unusual manner. That character (U+E0B0) works in all other Nerd Fonts I got installed (for instance Fira Code), just not with this Meslo variant, which is already a bit weird. Additionally my understanding is that block characters are expected to have approximately the same size as the font's advance width and height. While most Nerd Fonts variants are slightly incorrect in that regard, Meslo in particular is _really_ bad about this. This particular glyph for instance is almost 40% taller than the advance height it specifies which causes it to look like that. The only difference between build 2523 and 2642 is how those glyphs are vertically centered. In both screenshots you're missing more than half of that glyph - it's actually supposed to be a perfect triangle like this: ![image](https://user-images.githubusercontent.com/2256941/192419277-64440875-137a-4aa0-9e0a-fda2df68a1d5.png) Basically, IMO Nerd Fonts should stop making block glyphs taller than the font's advance height. In either case I'm going to simply revert the change that causes your issues: #14085
claunia commented 2026-01-31 06:15:34 +00:00
Author
Owner
Copy Link

@djdv commented on GitHub (Mar 9, 2023):

I was seeing the same rendering issue with the Powerline Extra block of glyphs, which was reported upstream:
https://github.com/ryanoasis/nerd-fonts/issues/1106 (my specific configuration https://github.com/ryanoasis/nerd-fonts/issues/1106#issuecomment-1423593788 renders similar to the OP of this issue).

This was resolved by a commit in their patcher https://github.com/ryanoasis/nerd-fonts/pull/1123

After using the latest version of my font, their patcher, and Terminal, at least those glyphs in my chosen fonts seem to render as expected now.

People in this thread may want to try them as well to get their renders back to how they looked before.
And it may be worth checking against their latest patcher revisions versus just the latest release when doing the Atlas refactor if it could potentially influence something here.

@djdv commented on GitHub (Mar 9, 2023): I was seeing the same rendering issue with the Powerline Extra block of glyphs, which was reported upstream: https://github.com/ryanoasis/nerd-fonts/issues/1106 (my specific configuration https://github.com/ryanoasis/nerd-fonts/issues/1106#issuecomment-1423593788 renders similar to the OP of this issue). This was resolved by a commit in their patcher https://github.com/ryanoasis/nerd-fonts/pull/1123 After using the latest version of my font, their patcher, and Terminal, at least those glyphs in my chosen fonts seem to render as expected now. People in this thread may want to try them as well to get their renders back to how they looked before. And it may be worth checking against their latest patcher revisions versus just the latest release when doing the Atlas refactor if it could potentially influence something here.
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 In-PR Issue-Bug Priority-2 Product-Terminal
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#18483
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?