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

Windows Terminal is Terrible #14472

New Issue
Closed
opened 2026-01-31 04:11:14 +00:00 by claunia · 26 comments
claunia commented 2026-01-31 04:11:14 +00:00
Owner
Copy Link

Originally created by @ghost on GitHub (Jul 12, 2021).

The development team is so full of excuses, and yet continue to make a terrible and slow terminal that:
1.) Can't render Arabic or Hebrew or any other RTL language correctly when other terminals are able to do so
2.) Can't render a 1GB file in under a second when other projects are able to do so
3.) Took over 20 years to add tabs
4.) Doesn't properly support RTL text input
5.) Continues to be much much slower than every single Linux terminal out there
6.) Makes excuses for adding glyph caching by trying to hand it off to a "framework" that doesn't do glyph caching yet:

Side note: DirectWrite doesn't necessarily cache glyphs between renderings. This is indeed something we could consider doing, but just absolutely isn't worth it, when the problem you have is caused by the number of calls and not the complexity to layout a couple ASCII letters.

  • lhecker

7.) Calls all of this "an entire doctoral research project in performant terminal emulation" when every other terminal is faster than it.
8.) The team clearly doesn't know how to do rendering very well, considering they are claiming 2D text rendering is so hard for them to do while actively using frameworks that are supposed to be designed for this exact purpose.
9.) Has very buggy animations since the beginning of the project
10.) Excuses poor performance because they designed the terminal badly from the very beginning, as shown here:

right now, we don’t have a single stage pipeline that uses a pixel shader to pull cell-glyphs from a texture. What we have instead is a rendering pipeline that emits up to 7,200 individual draw calls, and we’re talking about reducing that[1]. I’m not aiming for instant perfection, but simply trying to converge on a better solution. I can’t justify taking somebody offline for the months it would take to retool the entire renderer and then further justify dealing with the inevitable globalization issues that will follow to push thousands of frames per second when decoupling the renderer from the output pipeline gets the major performance bottleneck out of the way and better local draw call batching can get us in throwing distance of hundreds of fps.

  • DHowett

Firstly, you wouldn't have to take "somebody offline for the months it would take to retool the entire renderer" if you had written the renderer correctly to begin with. And secondly, what you've just described is called the Cost-Sunk Fallacy, and it's making your software worse.

11.) Intentionally knows that they are going to get more backlash for a terrible terminal, so they've prevented people from discussing this issue: https://github.com/microsoft/terminal/issues/10362
12.) Would rather sacrifice 100x performance slowdown for "readability and maintainability" because of incorrect ideology:

Do understand that some of the tuning tricks are not used for both readability and maintainability of the project.

  • skyline75489

Microsoft, fire your crappy developers and stop putting people who don't know how to do rendering in charge of rendering. There's a problem when every other terminal in existence is faster than your terminal, and has been for over 20 years.

You'd think after well over 6 decades of terminals being in existence we would have figured all of this out by now.
Hopefully DHowett is aware that video terminals have existed since the 1950s. The DEC VT100 was from 1978, even.

Originally created by @ghost on GitHub (Jul 12, 2021). The development team is so full of excuses, and yet continue to make a terrible and slow terminal that: 1.) Can't render Arabic or Hebrew or any other RTL language correctly when other terminals are able to do so 2.) Can't render a 1GB file in under a second when other projects are able to do so 3.) Took over 20 years to add tabs 4.) Doesn't properly support RTL text input 5.) Continues to be much much slower than every single Linux terminal out there 6.) Makes excuses for adding glyph caching by trying to hand it off to a "framework" that doesn't do glyph caching yet: > Side note: DirectWrite doesn't necessarily cache glyphs between renderings. This is indeed something we could consider doing, but just absolutely isn't worth it, when the problem you have is caused by the number of calls and not the complexity to layout a couple ASCII letters. > - lhecker 7.) Calls all of this "an entire doctoral research project in performant terminal emulation" when every other terminal is *faster* than it. 8.) The team clearly doesn't know how to do rendering very well, considering they are claiming *2D* text rendering is so hard for them to do *while* actively using frameworks that are *supposed to* be designed for this exact purpose. 9.) Has very buggy animations since the beginning of the project 10.) Excuses poor performance because they designed the terminal badly *from the very beginning*, as shown here: > right now, we don’t have a single stage pipeline that uses a pixel shader to pull cell-glyphs from a texture. What we have instead is a rendering pipeline that emits up to 7,200 individual draw calls, and we’re talking about reducing that[1]. I’m not aiming for instant perfection, but simply trying to converge on a better solution. I can’t justify taking somebody offline for the months it would take to retool the entire renderer and then further justify dealing with the inevitable globalization issues that will follow to push thousands of frames per second when decoupling the renderer from the output pipeline gets the major performance bottleneck out of the way and better local draw call batching can get us in throwing distance of hundreds of fps. > - DHowett Firstly, you wouldn't have to take "somebody offline for the months it would take to retool the entire renderer" if you had written the renderer correctly to begin with. And secondly, what you've just described is called the Cost-Sunk Fallacy, and it's making your software worse. 11.) Intentionally knows that they are going to get more backlash for a terrible terminal, so they've prevented people from discussing this issue: https://github.com/microsoft/terminal/issues/10362 12.) Would rather sacrifice 100x performance slowdown for "readability and maintainability" because of incorrect ideology: > Do understand that some of the tuning tricks are not used for both readability and maintainability of the project. > - skyline75489 Microsoft, fire your crappy developers and stop putting people who don't know how to do rendering in charge of rendering. There's a problem when every other terminal in existence is faster than your terminal, and has been for over 20 years. You'd think after well over 6 decades of terminals being in existence we would have figured all of this out by now. Hopefully DHowett is aware that video terminals have existed since the 1950s. The DEC VT100 was from 1978, even.
claunia added the Needs-TriageNeeds-Tag-Fix labels 2026-01-31 04:11:14 +00:00
claunia commented 2026-01-31 04:11:15 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

For people who want to see a terminal renderer demo that can parse VT100 escape sequences, render Arabic and Hebrew and Emojis correctly, with correct emoji colors, and can render a 12GB file in 14 seconds, and a 1GB file in under a second, look here:
https://github.com/cmuratori/refterm

Maybe someday the Microsoft teams will get their act together and stop excusing their poor performance for their tools. Particularly the VS team, the VS Code team, and the Terminal team.

And for a performant full cross-platform terminal, you can also try Alacritty: https://github.com/alacritty/alacritty

And just to prove that it's possible to do all of this, here's the YouTube demos showing all of this on-screen:
https://www.youtube.com/watch?v=hxM8QmyZXtg
https://www.youtube.com/watch?v=99dKzubvpKE

@ghost commented on GitHub (Jul 12, 2021): For people who want to see a terminal renderer demo that can parse VT100 escape sequences, render Arabic and Hebrew and Emojis correctly, with correct emoji colors, and can render a 12GB file in 14 seconds, and a 1GB file in under a second, look here: https://github.com/cmuratori/refterm Maybe someday the Microsoft teams will get their act together and stop excusing their poor performance for their tools. Particularly the VS team, the VS Code team, and the Terminal team. And for a performant full cross-platform terminal, you can also try Alacritty: https://github.com/alacritty/alacritty And just to prove that it's possible to do all of this, here's the YouTube demos showing all of this on-screen: https://www.youtube.com/watch?v=hxM8QmyZXtg https://www.youtube.com/watch?v=99dKzubvpKE
claunia commented 2026-01-31 04:11:16 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

Hi there! We have #10462 to track the performance issue you mentioned. And #538 for general RTL issue, if you’re interested.

Also I am actually NOT part of the official team. I do work for MS but I don’t work for the terminal team.

@skyline75489 commented on GitHub (Jul 12, 2021): Hi there! We have #10462 to track the performance issue you mentioned. And #538 for general RTL issue, if you’re interested. Also I am actually NOT part of the official team. I do work for MS but I don’t work for the terminal team.
claunia commented 2026-01-31 04:11:16 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

I appreciate your response, but what I want Microsoft to do is actually listen to people. Not make excuses. Not call things "doctoral research projects". Microsoft developers have been doing this for decades.

If you all are actually serious about this, the first step you need to be doing is recognizing that your terminal actually is slow. The next step is to not just dismiss what everyone has suggested - and this goes for every Microsoft developer, and to recognize that you've actually heard the feedback, for example, by repeating the feedback back to us (instead of using generic "your feedback has been heard" stuff).
And the 3rd step is to actually recognize the "research" of what other people have done, projects like refterm and Alacritty and other terminals.

For example, responses like this below are not helpful! You guys have DirectWrite and Uniscribe that's supposed to do this stuff! Why aren't you using it? You should be able to print RTL, at the very least, by now.

We're all for adding RTL support, but know that doing that would require a lot of work.

@ghost commented on GitHub (Jul 12, 2021): I appreciate your response, but what I want Microsoft to do is actually *listen* to people. Not make excuses. Not call things "doctoral research projects". Microsoft developers have been doing this for decades. If you all are actually serious about this, the first step you need to be doing is recognizing that your terminal actually *is* slow. The next step is to not just dismiss what everyone has suggested - and this goes for *every* Microsoft developer, and to recognize that you've *actually* heard the feedback, for example, by repeating the feedback back to us (instead of using generic "your feedback has been heard" stuff). And the 3rd step is to actually recognize the "research" of what other people have done, projects like refterm and Alacritty and other terminals. For example, responses like this below are not helpful! You guys have DirectWrite *and* Uniscribe that's supposed to do this stuff! Why aren't you using it? You should be able to *print* RTL, at the very least, by now. > We're all for adding RTL support, but know that doing that would require a lot of work.
claunia commented 2026-01-31 04:11:17 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

Sure. I think it's basically a common understanding for everyone in the team that both conhost & Windows Terminal is slower than the terminals on Linux. In fact the entire console system was not just slow, but overall terrible before the ConPTY refactoring. Back then one actually needs to use projects like winpty to build a third-party terminal application, which basically read all the things on the screen & convert them to VT codes. How crazy is that? Right now with ConPTY, things are better, but still not ideal. The performance gap between ConPTY & the pty on Linux is huge right now, which is not news to you, and everyone else.

The renderer work (refterm) as you mentions is recognized in #10461. However due to licensing issue, no one in the team is allowed to see the code (GPL-licensed). This even includes outside contributors like me. MS treats license issue very seriously, because some of the code in this repo will be merged back into Windows itself. The last thing MS want would be licensing issue inside Windows source code.

For RTL support, I don't know much about it, so I'm not commenting on that.

@skyline75489 commented on GitHub (Jul 12, 2021): Sure. I think it's basically a common understanding for everyone in the team that both conhost & Windows Terminal is slower than the terminals on Linux. In fact the entire console system was not just slow, but overall terrible before the [ConPTY](https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/) refactoring. Back then one actually needs to use projects like [winpty](https://github.com/rprichard/winpty) to build a third-party terminal application, which basically read all the things on the screen & convert them to VT codes. How crazy is that? Right now with ConPTY, things are better, but still not ideal. The performance gap between ConPTY & the pty on Linux is huge right now, which is not news to you, and everyone else. The renderer work (refterm) as you mentions is recognized in #10461. However due to licensing issue, no one in the team is allowed to see the code (GPL-licensed). This even includes outside contributors like me. MS treats license issue very seriously, because some of the code in this repo will be merged back into Windows itself. The last thing MS want would be licensing issue inside Windows source code. For RTL support, I don't know much about it, so I'm not commenting on that.
claunia commented 2026-01-31 04:11:18 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

Do understand that some of the tuning tricks are not used for both readability and maintainability of the project.

That is my word. The specific issue I refer to in that thread is fixed in #10426, which sadly doesn't bring 3X performance boost because the original code is flawed in a way that bypasses the worst case. If you're interested, check out this comment https://github.com/microsoft/terminal/issues/10462#issuecomment-874376254 to see what's been done since the initial issue #10362.

@skyline75489 commented on GitHub (Jul 12, 2021): > Do understand that some of the tuning tricks are not used for both readability and maintainability of the project. That is my word. The specific issue I refer to in that thread is fixed in #10426, which sadly doesn't bring 3X performance boost because the original code is flawed in a way that bypasses the worst case. If you're interested, check out this comment https://github.com/microsoft/terminal/issues/10462#issuecomment-874376254 to see what's been done since the initial issue #10362.
claunia commented 2026-01-31 04:11:18 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

You guys aren't blocked from the YT videos Casey made, I assume?

What about Glyph Caching? Has that been implemented yet? You guys have had a month to implement that.
Have you considered rebuilding the terminal from the ground-up (starting from scratch)? Considering that it took Casey so little time to implement all of this, the cost of starting over seems to be smaller than the cost of trying to fix something that's already terribly broken.

@ghost commented on GitHub (Jul 12, 2021): You guys aren't blocked from the YT videos Casey made, I assume? What about Glyph Caching? Has that been implemented yet? You guys have had a month to implement that. Have you considered rebuilding the terminal from the ground-up (starting from scratch)? Considering that it took Casey so little time to implement all of this, the cost of starting over seems to be smaller than the cost of trying to fix something that's already terribly broken.
claunia commented 2026-01-31 04:11:18 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

If by "Glyph Caching". you mean the "glyph atlas renderer", that is tracked in #10461 which is assigned to @lhecker himself.

If you're talking about the internal issue inside DirectWrite, I think @lhecker has recently contacted some person in DirectWrite team and he may have something to say bout this one. I had the idea way back in #6300 for some run-level caching, but I didn't go further.

If you only care about the renderer part, the work in #10461 can be seen as "from the ground-up". It will be a brand new renderer. And I think Leonard have seen some promising result with his prototype. If you want a brand new terminal from ground-up, that would require other works than just the renderer.

@skyline75489 commented on GitHub (Jul 12, 2021): If by "Glyph Caching". you mean the "glyph atlas renderer", that is tracked in #10461 which is assigned to @lhecker himself. If you're talking about the internal issue inside DirectWrite, I think @lhecker has recently contacted some person in DirectWrite team and he may have something to say bout this one. I had the idea way back in #6300 for some run-level caching, but I didn't go further. If you only care about the renderer part, the work in #10461 can be seen as "from the ground-up". It will be a brand new renderer. And I think Leonard have seen some promising result with his prototype. If you want a brand new *terminal* from ground-up, that would require other works than just the *renderer*.
claunia commented 2026-01-31 04:11:18 +00:00
Author
Owner
Copy Link

@shawnz commented on GitHub (Jul 12, 2021):

Works fine for me. If you hate the direction of the project so much shouldn't you consider just using a different one?

@shawnz commented on GitHub (Jul 12, 2021): Works fine for me. If you hate the direction of the project so much shouldn't you consider just using a different one?
claunia commented 2026-01-31 04:11:19 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

Now if only y'all had recognized all of this originally rather than making excuses and then doing it after the fact.

@ghost commented on GitHub (Jul 12, 2021): Now if only y'all had recognized all of this *originally* rather than making excuses and then doing it *after the fact*.
claunia commented 2026-01-31 04:11:19 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

Some people might think that everybody is fussing over terminal performance for no practical benefit.

But this actually reveals a very big cultural problem where performance is never taken seriously to the point that the majority of applications on systems are now dramatically slower than they should be (aside from video games), and to the point that every single benefit we've gained from newer CPUs has been diminished because of this.

By not taking even the most basic of performance considerations seriously, you are teaching the new programmers who are looking to existing programmers that either there's nothing that can be done, when that is far from the truth, or that performance isn't worth it somehow.

@ghost commented on GitHub (Jul 12, 2021): Some people might think that everybody is fussing over terminal performance for no practical benefit. But this actually reveals a *very big* cultural problem where performance is never taken seriously to the point that the majority of applications on systems are now dramatically slower than they should be (aside from video games), and to the point that every single benefit we've gained from newer CPUs has been diminished because of this. By not taking even the *most basic* of performance considerations seriously, you are teaching the new programmers who are looking to existing programmers that either there's nothing that can be done, when that is far from the truth, or that performance isn't worth it somehow.
claunia commented 2026-01-31 04:11:19 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

A list of the issues @skyline75489 has posted above:

@ghost commented on GitHub (Jul 12, 2021): A list of the issues @skyline75489 has posted above: * https://github.com/microsoft/terminal/issues/10362 * https://github.com/microsoft/terminal/issues/10462 * https://github.com/microsoft/terminal/issues/10461 * https://github.com/microsoft/terminal/issues/6300 * https://github.com/microsoft/terminal/issues/538
claunia commented 2026-01-31 04:11:19 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

Now if only y'all had recognized all of this originally rather than making excuses and then doing it after the fact.

I personally wish this hadn't turned into some kind of flame war in the first place. The original issue was full of misunderstanding & miscommunication. I am one of them to blame, if there has to be someone to blame.

performance is never taken seriously

To speak on my own behalf, this terminal team I know of, take performance very seriously. In fact my earliest PRs are almost all about performance, because the performance of the Windows Terminal ~0.6, is just terrible. Way more terrible than the terminal you see today. I've sent various kinds of perf PRs. The members from the official team also write various kinds of perf PRs. I've never seen the members of the team saying "hey this PR is about performance, and we don't care about them". Never have I seen anything like that.

Again, in #10362 there's a lot of unnecessary emotions flowing around, which stepped in the way of efficient communication and make people feel that they are dismissed. But that's not the team I know of. The team I know of is full of talented engineers and they're very passionate about the project. They have been maintaining the project for 5-6 years. If the project was a newborn, it could already know TikTok now.

But what's done is done. The best we can do it to recognize the mistakes, learn from them and try to move on.

@skyline75489 commented on GitHub (Jul 12, 2021): > Now if only y'all had recognized all of this _originally_ rather than making excuses and then doing it _after the fact_. I personally wish this hadn't turned into some kind of flame war in the first place. The original issue was full of misunderstanding & miscommunication. I am one of them to blame, if there has to be someone to blame. > performance is never taken seriously To speak on my own behalf, this terminal team I know of, take performance very seriously. In fact my earliest PRs are almost all about performance, because the performance of the Windows Terminal ~0.6, is just terrible. Way more terrible than the terminal you see today. I've sent various kinds of perf PRs. The members from the official team also write various kinds of perf PRs. I've never seen the members of the team saying "hey this PR is about performance, and we don't care about them". Never have I seen anything like that. Again, in #10362 there's a lot of unnecessary emotions flowing around, which stepped in the way of efficient communication and make people feel that they are dismissed. But that's not the team I know of. The team I know of is full of talented engineers and they're very passionate about the project. They have been maintaining the project for 5-6 years. If the project was a newborn, it could already know TikTok now. But what's done is done. The best we can do it to recognize the mistakes, learn from them and try to move on.
claunia commented 2026-01-31 04:11:20 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

@skyline75489 I personally don't understand what all of the emotions and dismissing was for. Casey point out things that you could do better, politely imho (I read everything he said, I personally didn't think he said anything inflammatory in that specific issue), and then was met by people, imo, overestimating the work that needed to be done and outright dismissing his suggestions. He even asked what the hard part was.

In fact, I would say Casey was way more polite than usual :D
Especially considering how he hasn't always had the best interactions with the Visual Studio team

@ghost commented on GitHub (Jul 12, 2021): @skyline75489 I personally don't understand what all of the emotions and dismissing was for. Casey point out things that you could do better, politely imho (I read everything he said, I personally didn't think he said anything inflammatory in that specific issue), and then was met by people, imo, overestimating the work that needed to be done and outright dismissing his suggestions. He even asked what the hard part was. In fact, I would say Casey was way more polite than usual :D Especially considering how he hasn't always had the best interactions with the Visual Studio team
claunia commented 2026-01-31 04:11:20 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

You're free to have your opinion on whatever it's in #10362. I can't speak for anyone but myself. Let's just say we are all just humans and make mistakes.

If you don't mind, I think we should close this issue and redirect future discussion to #10462 . This thread isn't really about technical aspects anymore. If you really want to talk about it, you're free to go over to my repo where I wrote a bit more explanation.

Everything we said here will generate an email for everyone who watches this project, and I don't want to annoy them too much with my personal opinions & non-tech talks.

@skyline75489 commented on GitHub (Jul 12, 2021): You're free to have your opinion on whatever it's in #10362. I can't speak for anyone but myself. Let's just say we are all just humans and make mistakes. If you don't mind, I think we should close this issue and redirect future discussion to #10462 . This thread isn't really about technical aspects anymore. If you really want to talk about it, you're free to go over to my [repo](https://github.com/skyline75489/AMA/issues/1) where I wrote a bit more explanation. Everything we said here will generate an email for everyone who watches this project, and I don't want to annoy them too much with my personal opinions & non-tech talks.
claunia commented 2026-01-31 04:11:20 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

If you really want to talk about it, you're free to go over to my repo where I wrote a bit more explanation.
(https://github.com/skyline75489/AMA/issues/1)

I feel like this should have been posted to here instead.

Just note that this response, below, is probably the reason why this "controversy" is ongoing:

Refterm is fast monospace text displayer, but it's NOT a terminal. This is not my word. This is what you'll see in refterm itself (shown in the video). If someone makes a functional terminal out of refterm (without too much performance drop), I'll be thrilled to try it out myself.

You are continuing to dismiss rendering performance on the basis that refterm doesn't inplement non-rendering features that wouldn't necessarily slow down the rendering anyways - even though, refterm doesn't seem to be that far from an actual terminal, afaik.
I hope you are not serious that the rest of the features refterm would need to support would slow down the terminal so much that it drops that much in performance.

@ghost commented on GitHub (Jul 12, 2021): > If you really want to talk about it, you're free to go over to my repo where I wrote a bit more explanation. (https://github.com/skyline75489/AMA/issues/1) I feel like this should have been posted to here instead. Just note that this response, below, is probably the reason why this "controversy" is ongoing: > Refterm is fast monospace text displayer, but it's NOT a terminal. This is not my word. This is what you'll see in refterm itself (shown in the video). If someone makes a functional terminal out of refterm (without too much performance drop), I'll be thrilled to try it out myself. You are continuing to dismiss **rendering performance** on the basis that refterm doesn't inplement non-rendering features that wouldn't necessarily slow down the rendering anyways - even though, refterm doesn't seem to be that far from an actual terminal, afaik. I hope you are not serious that the rest of the features refterm would need to support would slow down the terminal so much that it drops that much in performance.
claunia commented 2026-01-31 04:11:20 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

refterm doesn't seem to be that far from an actual terminal,

I suggest you read the "legacy code" section of my section. Or my previous comment suggesting one need to use WinPTY to build a terminal (https://github.com/microsoft/terminal/issues/10623#issuecomment-878012390). The main reason behind this is that, legacy console applications does NOT speak VT at all. You can support all the VT code in the word, but legacy console applications on Windows won't work in a terminal that only understands VT, this includes Win32-Vim, Far Manager, mc, old version of Git Bash/MINGW. The list goes on.

This kind of legacy is a huge burden to Windows Terminal, both architectural-wise & performance wise. One example of this is Alacritty, which is a super fast terminal on Linux/macOS, regarding rendering performance. But on Windows, due to ConPTY (if you use ConPTY, then you can build your terminals using just VT, this is how Windows Terminal is now), Alacritty is severely slowed down.

I'm not finding excuses, In fact it only shows how bad ConPTY is, And we're tracking the work in this repo to improve that performance.

@skyline75489 commented on GitHub (Jul 12, 2021): > refterm doesn't seem to be that far from an actual terminal, I suggest you read the "legacy code" section of my section. Or my previous comment suggesting one need to use WinPTY to build a terminal (https://github.com/microsoft/terminal/issues/10623#issuecomment-878012390). The main reason behind this is that, legacy console applications does NOT speak VT at all. You can support all the VT code in the word, but legacy console applications on Windows won't work in a terminal that only understands VT, this includes Win32-Vim, Far Manager, mc, old version of Git Bash/MINGW. The list goes on. This kind of legacy is a huge burden to Windows Terminal, both architectural-wise & performance wise. One example of this is Alacritty, which is a super fast terminal on Linux/macOS, regarding rendering performance. But on Windows, due to ConPTY (if you use ConPTY, then you can build your terminals using just VT, this is how Windows Terminal is now), Alacritty is severely slowed down. I'm not finding excuses, In fact it only shows how bad ConPTY is, And we're tracking the work in this repo to improve that performance.
claunia commented 2026-01-31 04:11:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

Just because refterm doesn't handle legacy applications doesn't make it any less of a terminal. What makes it not a terminal, I assume, is mostly the input stuff (for both keyboard and mouse).

Various linux terminals don't handle legacy win32 console applications, are they also not terminals? Does them being so much faster than Windows Terminal suddenly not matter because they don't support legacy win32 console applications?

And do you actually know that you can't get a terminal with similar performance to refterm while also supporting legacy win32 console apps, or are we just assuming this?

Sorry, but to me it sounded like you were trying to cast doubt on refterm's performance by twisting the notice that refterm isn't a terminal.

@ghost commented on GitHub (Jul 12, 2021): Just because refterm doesn't handle legacy applications doesn't make it any less of a terminal. What makes it not a terminal, I assume, is mostly the input stuff (for both keyboard and mouse). Various linux terminals don't handle legacy win32 console applications, are they also not terminals? Does them being so much faster than Windows Terminal suddenly not matter because they don't support legacy win32 console applications? And do you actually know that you can't get a terminal with similar performance to refterm while also supporting legacy win32 console apps, or are we just assuming this? Sorry, but to me it sounded like you were trying to cast doubt on refterm's performance by twisting the notice that refterm isn't a terminal.
claunia commented 2026-01-31 04:11:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

It actually takes a surprisingly long time to make a fully functional, daily usable terminal. Alacritty was launched in 2017. GNOME terminal has at least 20 years of history. And veterans like XTerm & rxvt & everything in that era are even older. What's even frustrating is that, the performance of GNOME is still not that good. Alacritty still has no support for ligatures. I'm not trying to diss these products, or find excuses for Windows Terminal. In fact I think they show us what a good terminal can/should do. I guess the road to perfection is just inevitably long.

By the looks of it, you're trying to twist facts to make it seem like Terminals are harder than they actually are, which is the same thing that other contributors to Windows Terminal did in the original thread.

Alacritty was functional and fast in 2018. It didn't take them 5 years to get a functional and fast terminal emulator.
It also didn't take GNOME terminal 20 years to become functional. Most of that time is called maintenance (or adding extra features).

@ghost commented on GitHub (Jul 12, 2021): > It actually takes a surprisingly long time to make a fully functional, daily usable terminal. Alacritty was launched in 2017. GNOME terminal has at least 20 years of history. And veterans like XTerm & rxvt & everything in that era are even older. What's even frustrating is that, the performance of GNOME is still not that good. Alacritty still has no support for ligatures. I'm not trying to diss these products, or find excuses for Windows Terminal. In fact I think they show us what a good terminal can/should do. I guess the road to perfection is just inevitably long. By the looks of it, you're trying to twist facts to make it seem like Terminals are harder than they actually are, which is the *same thing* that other contributors to Windows Terminal did in the original thread. Alacritty was *functional and fast* **in 2018**. It didn't take them 5 years to get a functional and fast terminal emulator. It also didn't take GNOME terminal 20 years to become functional. Most of that time is called maintenance (or adding extra features).
claunia commented 2026-01-31 04:11:21 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

I'm not sure if you want a "Windows" Terminal or "Linux" terminal, because I just talked about how fundamentally different the console subsystem is between Windows & Linux. Of course this is no excuse for Windows Terminal to be slow than those on Linux. It just takes time, I think. The ConPTY article was in 2018, I'm guessing that's about the time that MS tried to improve the console subsystem.

And do you actually know that you can't get a terminal with similar performance to refterm while also supporting legacy win32 console apps, or are we just assuming this?

I'm glad you asked. There's this similar project https://github.com/jfhs/handterm which does use ConPTY and aims to have better performance. It's actually quite good (also MIT-licensed). It's faster than Windows Terminal & conhost. It's still in its early development, though. I'm really looking forward to see how it will turn out to be in the future.

you were trying to cast doubt on refterm's performance by twisting the notice that refterm isn't a terminal.

I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it.

I can't really control how you feel about my article. I meant to only talk about fact, and not opinions. I think I made it clear in that article of mine. I have huge respects for authors behind Alacritty & GNOME terminals. I'm hoping they have the same respect for people who built Windows Terminal.

Again, I'm kindly asking you to move this discussion somewhere else, because I don't want to harass people with non-tech talks. I love to see Github as a tech-only place, even it's just a dream.

@skyline75489 commented on GitHub (Jul 12, 2021): I'm not sure if you want a "Windows" Terminal or "Linux" terminal, because I just talked about how fundamentally different the console subsystem is between Windows & Linux. Of course this is no excuse for Windows Terminal to be slow than those on Linux. It just takes time, I think. The ConPTY article was in 2018, I'm guessing that's about the time that MS tried to improve the console subsystem. >And do you actually know that you can't get a terminal with similar performance to refterm while also supporting legacy win32 console apps, or are we just assuming this? I'm glad you asked. There's this similar project https://github.com/jfhs/handterm which does use ConPTY and aims to have better performance. It's actually quite good (also MIT-licensed). It's faster than Windows Terminal & conhost. It's still in its early development, though. I'm really looking forward to see how it will turn out to be in the future. > you were trying to cast doubt on refterm's performance by twisting the notice that refterm isn't a terminal. I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it. I can't really control how you feel about my article. I meant to only talk about fact, and not opinions. I think I made it clear in that article of mine. I have huge respects for authors behind Alacritty & GNOME terminals. I'm hoping they have the same respect for people who built Windows Terminal. Again, I'm kindly asking you to move this discussion somewhere else, because I don't want to harass people with non-tech talks. I love to see Github as a tech-only place, even it's just a dream.
claunia commented 2026-01-31 04:11:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it.

Why is it not a terminal? You seem to be suggesting in the article it's not a terminal because it doesn't support legacy win32 console apps. Yet there are various terminals on Windows that only do VT100. Again, are those suddenly not terminals?

Refterm is certainly not a terminal yet, but it's not because it doesn't support win32 legacy console apps, as you seem to suggest.

Let me just make this clear, a terminal emulator is an emulator that emulates any terminal, like DEC VT100, VT102, etc. If a program emulates all of DEC VT100, it is a terminal emulator. It's that plain and simple.

I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it.

This is exactly what you are trying to do. You are subtly hinting that refterm is only as fast as it is because it's not a terminal, and that had it been a real terminal, it would suddenly be significantly slower. The fact is that you don't actually know that. You can continue the rhetoric all you want, but I can see right past it.

I meant to only talk about fact, and not opinions.

Except you talk about opinions right within the article, so...

@ghost commented on GitHub (Jul 12, 2021): > I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it. Why is it *not* a terminal? You seem to be suggesting in the article it's not a terminal because it doesn't support legacy win32 console apps. Yet there are various **terminals** on Windows that only do VT100. Again, are those suddenly not terminals? Refterm is certainly not a terminal yet, but it's not **because** it doesn't support win32 legacy console apps, as you seem to suggest. Let me just make this clear, a terminal emulator is an emulator that emulates *any* terminal, like DEC VT100, VT102, etc. If a program emulates all of DEC VT100, it **is** a terminal emulator. It's that plain and simple. > I don't want to cast doubt on anything. If by "terminal" we mean a terminal we can daily drive with, then refterm is indeed NOT a terminal, right? If by "terminal" we mean "it can render text", then I guess I should be clearer about it. This is exactly what you are trying to do. You are subtly hinting that refterm is only as fast as it is *because* it's not a terminal, and that had it been a real terminal, it would suddenly be significantly slower. The *fact* is that you don't actually know that. You can continue the rhetoric all you want, but I can see right past it. > I meant to only talk about fact, and not opinions. Except you talk about opinions right within the article, so...
claunia commented 2026-01-31 04:11:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

Here's what I see...
1.) You are trying to impugn other people's claims by implying that terminals are harder than they really are, and by overestimating the time it takes to make a terminal emulator.
2.) You are trying to impugn other terminal projects' performance benchmarks by implying that they have to do less than what you "must" do.
3.) You are trying to impugn certain terminal projects by implying they aren't even that close to being a terminal, let alone actually being a terminal.
4.) You tried to impugn everything I said by implying that I'm only talking about opinions, when from the very start it was the Windows Terminal team that has been doing this, at least up until they were proven wrong.

@ghost commented on GitHub (Jul 12, 2021): Here's what I see... 1.) You are trying to impugn other people's claims by implying that terminals are harder than they really are, and by overestimating the time it takes to make a terminal emulator. 2.) You are trying to impugn other terminal projects' performance benchmarks by implying that they have to do less than what you "*must*" do. 3.) You are trying to impugn certain terminal projects by implying they aren't even that close to being a terminal, let alone actually being a terminal. 4.) You tried to impugn everything I said by implying that I'm only talking about opinions, when from the very start it was the Windows Terminal team that has been doing this, at least up until they were **proven wrong**.
claunia commented 2026-01-31 04:11:22 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jul 12, 2021):

I've changed some of words in the article. I made it abundantly clear that, by terminal I mean you can daily drive with it using all kinds of applications include legacy apps & VT apps, basically offers same level of functionality as conhost & Windows Terminal.

it would suddenly be significantly slower

I don't want it to be slow. If refterm/handterm turns out to be very fast & fully functional, I would probably ditch Windows Terminal. Why not? Please don't assume that we're all just bots controlled by Microsoft. Everyone has the free will to choose whatever they like to use. You can even use GNOME terminal right here on Windows, thanks to WSLg. To quote Dustin's word, Windows Terminal is never meant to be the only choice. Just like every other apps that comes with the OS (sry, paint.exe).

Except you talk about opinions right within the article

Well I tried to be. I can not make everyone happy, that's for sure.

Here's what I see...

You can completely ignore my opinions. I am not officially related to this project. I contribute to this project for fun. I answered you issue because I want to be helpful. What does all those "impugn" gain me? Self-esteem? Like I said, I would probably ditch Windows Terminal the second I found a better one. Does this help defending myself?

Sorry everyone who's harassed by all these lengthy emails from me. This will be my last for the day.

@skyline75489 commented on GitHub (Jul 12, 2021): I've changed some of words in the article. I made it abundantly clear that, by terminal I mean you can daily drive with it using all kinds of applications include legacy apps & VT apps, basically offers same level of functionality as conhost & Windows Terminal. > it would suddenly be significantly slower I *don't* want it to be slow. If refterm/handterm turns out to be very fast & fully functional, I would probably ditch Windows Terminal. Why not? Please don't assume that we're all just bots controlled by Microsoft. Everyone has the free will to choose whatever they like to use. You can even use GNOME terminal right here on Windows, thanks to WSLg. To quote Dustin's word, Windows Terminal is never meant to be the only choice. Just like every other apps that comes with the OS (sry, paint.exe). > Except you talk about opinions right within the article Well I tried to be. I can not make everyone happy, that's for sure. > Here's what I see... You can completely ignore my opinions. I am not officially related to this project. I contribute to this project for fun. I answered you issue because I want to be helpful. What does all those "impugn" gain me? Self-esteem? Like I said, I would probably ditch Windows Terminal the second I found a better one. Does this help defending myself? Sorry everyone who's harassed by all these lengthy emails from me. This will be my last for the day.
claunia commented 2026-01-31 04:11:22 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

So... to summarize, it took 29 days for someone to make a whole conhost replacement that's faster than windows's conhost (even if it's unstable, it still proves my point), and it took a couple of weeks for someone to make a vastly more performant terminal emulator renderer.

What exactly has the Terminal team been doing for the past 3-4 years?!?
(and let us just remember that handterm is made by one person so far, without funding afaik, while Microsoft is this giant company with many many developers)

@ghost commented on GitHub (Jul 12, 2021): So... to summarize, it took 29 days for someone to make a whole conhost replacement that's faster than windows's conhost (even if it's unstable, it still proves my point), and it took a couple of weeks for someone to make a vastly more performant terminal emulator *renderer*. What exactly has the Terminal team been doing for the past 3-4 years?!? (and let us just remember that handterm is made by *one person* so far, without funding afaik, while Microsoft is this giant company with many many developers)
claunia commented 2026-01-31 04:11:22 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

You can completely ignore my opinions. I am not officially related to this project. I contribute to this project for fun. I answered you issue because I want to be helpful. What does all those "impugn" gain me? Self-esteem? Like I said, I would probably ditch Windows Terminal the second I found a better one. Does this help defending myself?

@skyline75489 It sounds to me like you're trying to defend the Windows Terminal team, which makes sense, especially if you know the people.

The part you didn't take into account is that it's not helpful to those people to coddle them.

@ghost commented on GitHub (Jul 12, 2021): > You can completely ignore my opinions. I am not officially related to this project. I contribute to this project for fun. I answered you issue because I want to be helpful. What does all those "impugn" gain me? Self-esteem? Like I said, I would probably ditch Windows Terminal the second I found a better one. Does this help defending myself? @skyline75489 It sounds to me like you're trying to defend the Windows Terminal team, which makes sense, especially if you know the people. The part you didn't take into account is that it's not helpful to those people to coddle them.
claunia commented 2026-01-31 04:11:22 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 12, 2021):

Let's just take a look, for a second, at the general trends that Microsoft has been going in:

  • Since VS 2010, Visual studio has been getting slower and slower with each new release
    • Took over a decade to add 64-bit support
    • Increased C# usage (instead of C++)
    • Increased OOP, Garbage Collection, and .NET usage
    • Increased Memory, Increased CPU
    • Decreased Performance
  • Visual Studio Code - one of the slowest text editors, but hey! At least it's faster than Atom!
    • Electron: JS, HTML, and CSS
    • Increased OOP and Garbage Collection compared to alternatives
    • Increased Memory, Increased CPU compared to alternatives
    • Decreased Performance compared to alternatives
  • IE/Old Microsoft Edge
    • Increased OOP
    • Increased C#
    • Increased Memory, Increased CPU
    • Decreased Performance
  • UWP
    • Increased C#, and OOP, and GC
    • Increased Memory, Increased CPU
    • Decreased Performance
  • Windows
    • Increased OOP, Increased C# and .NET
    • Increased Memory, Increased CPU
    • Decreased Performance in the places that used .NET or UWP, in particular
  • Windows Image Viewer -> Pictures app
    • Increased OOP, Increased C# and .NET
    • Increased Memory, Increased CPU
    • Decreased Performance
  • Windows Calculator
    • Increased OOP, Increased C# and .NET
    • Increased Memory, Increased CPU
    • Decreased Performance
  • Windows Terminal, Conhost, ConPTY, etc.
    • Increased OOP, Increased C# and .NET, Increased layers
    • Increased Memory, Increased CPU
    • Decreased Performance
@ghost commented on GitHub (Jul 12, 2021): Let's just take a look, for a second, at the general trends that Microsoft has been going in: * Since VS 2010, Visual studio has been getting slower and slower with each new release - Took over a decade to add 64-bit support - Increased C# usage (instead of C++) - Increased OOP, Garbage Collection, and .NET usage - Increased Memory, Increased CPU - Decreased Performance * Visual Studio Code - one of the slowest text editors, but hey! At least it's faster than Atom! - Electron: JS, HTML, and CSS - Increased OOP and Garbage Collection compared to alternatives - Increased Memory, Increased CPU compared to alternatives - Decreased Performance compared to alternatives * IE/Old Microsoft Edge - Increased OOP - Increased C# - Increased Memory, Increased CPU - Decreased Performance * UWP - Increased C#, and OOP, and GC - Increased Memory, Increased CPU - Decreased Performance * Windows - Increased OOP, Increased C# and .NET - Increased Memory, Increased CPU - Decreased Performance in the places that used .NET or UWP, in particular * Windows Image Viewer -> Pictures app - Increased OOP, Increased C# and .NET - Increased Memory, Increased CPU - Decreased Performance * Windows Calculator - Increased OOP, Increased C# and .NET - Increased Memory, Increased CPU - Decreased Performance * Windows Terminal, Conhost, ConPTY, etc. - Increased OOP, Increased C# and .NET, Increased layers - Increased Memory, Increased CPU - Decreased Performance
claunia commented 2026-01-31 04:11:22 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 12, 2021):

@krixano Sorry that you've now been dragged into this whole debate that was spawned from a simple misunderstanding. We're actually really interested in a lot of the optimizations that were suggested in the original thread! It's a shame that our particular brand of sarcastic, self-deprecating humor in the original thread happened to spawn an entire flame war that's gone on entirely too long.

We're tracking some discrete improvements to the Terminal over in #10461, #10462, #7147, #3515, and pretty much anything else tagged Area-Performance. We'd love constructive feedback on those threads, or even contributions if you have any ideas of your own!

As the rest of this thread hasn't been particularly constructive, I'm gonna lock it to let everyone cool down a bit.

@zadjii-msft commented on GitHub (Jul 12, 2021): @krixano Sorry that you've now been dragged into this whole debate that was spawned from a simple misunderstanding. We're actually really interested in a lot of the optimizations that were suggested in the original thread! It's a shame that our particular brand of sarcastic, self-deprecating humor in the original thread happened to spawn an entire flame war that's gone on entirely too long. We're tracking some discrete improvements to the Terminal over in #10461, #10462, #7147, #3515, and pretty much anything else tagged [`Area-Performance`](https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+label%3AArea-Performance+). We'd love constructive feedback on those threads, or even contributions if you have any ideas of your own! As the rest of this thread hasn't been particularly constructive, I'm gonna lock it to let everyone cool down a bit.
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 Needs-Tag-Fix Needs-Triage
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#14472
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?