Windows Terminal is Terrible

[ghost]

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: #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.

[skyline75489]

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]

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]

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

[ghost]

A list of the issues @skyline75489 has posted above:

• Extremely slow performance when processing virtual terminal sequences #10362
• Extremely slow performance when processing virtual terminal sequences #10462
• Add a DxRenderer based on a glyph atlas #10461
• Text layout caching by run #6300
• Support Right to Left (RTL) text #538

[skyline75489]

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]

@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

[zadjii-msft]

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