search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.38k stars 8.3k forks source link

Windows Terminal is Terrible #10623

Closed ghost closed 3 years ago

ghost commented 3 years ago

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.

ghost commented 3 years ago

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

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

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.

skyline75489 commented 3 years ago

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 3 years ago

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.

ghost commented 3 years ago

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.

skyline75489 commented 3 years ago

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.

shawnz commented 3 years ago

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

ghost commented 3 years ago

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

ghost commented 3 years ago

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 3 years ago

A list of the issues @skyline75489 has posted above:

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

@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

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

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.

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

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 3 years ago

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).

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

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 3 years ago

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.

skyline75489 commented 3 years ago

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.

ghost commented 3 years ago

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 3 years ago

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 3 years ago

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

zadjii-msft commented 3 years ago

@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.