> Update May 9, 2022: This article was originally published without giving proper credit where it is due. We would like to thank Joe Wilm of Alacritty for establishing modern GPU terminal rendering, Christian Parpart of Contour for the continued support and advice, and Tom Szilagyi for describing the idea previously. Special thanks to Casey Muratori for suggesting this approach and Mārtiņš Možeiko for providing a reference HLSL shader. I deeply apologize to everyone mentioned. Additionally, a wording mistake was corrected in the previous paragraph.
BTW, the basic idea of keeping a texture atlas that contains a cache of the most used render elements isn't really that novel. It has already been done way before in the past by game engine devs who were trying to create 2D sprite renderers that automatically batch sprite textures to save draw calls (on runtime without any preprocessing step). Some examples I could find:
It's a simple and relatively straightforward approach that a sufficiently bright programmer would come up in their own while looking at the design constraints though, so overall I find it a bit meaningless to find the ultimate person for the "original idea".
Absolutely, Casey didn't really care about attribution, but he was angry that the devs have dismissed this simple approach as being too complex even if it was the most obvious design decision to do.
I can give you that he is condescending towards software and also towards complexity if he sees it as non-complex. And yes, agree that it didn't help (although they dismissed the suggestions before that)
Not sure where you see the condescending manner in that thread. Honestly having read about this storm-in-a-teacup in various discussions without having previously read the thread that started it, it all seems remarkably mild and polite compared to expectations.
At the end you can see Casey is getting frustrated and doesn't really understand the WT team's responses, or why they're making a big deal out of it. The WT team in the meantime clearly feel they have higher priorities than raising performance in their legacy code, don't relish tossing their rendering pipeline to make a new one, and don't understand why Casey is so focused on performance. But they're definitely trying to find some mutual understanding and Casey is clearly trying to help them. There are way worse programmers-butting-heads threads out there.
Here's a controversial thought: the reason this blew up in such a big way isn't really to do with any of the people involved or their tone on some random GH issue but rather what this says about Microsoft and the general decay of the Windows platform. That frustration is widespread and totally understandable. The Microsoft devs on that thread all come across as very nice and reasonable people, but they also come across as inexperienced and out of their depth. This problem is not unique to that team. Microsoft are charging good money for this stuff (not WT directly but Windows as a whole). Many, many people are forced to deal with Windows whether they want to or not and end up having to deal with poor implementations even if they'd rather be using Linux or macOS.
The WT devs are IMO doing way better than the average dev working on Windows - they engaged seriously and honestly dev-to-dev, they admitted when they were wrong, they improved the product, and they've even given credit to the people who embarrassed them in public. If only everyone were so good natured!
I won't say which area because this is my anon account and I reported some bugs publicly but I've recently been dealing with a different Windows team (as an outsider) and smacking right into the exact same problem. The task their subsystem handles is a very easy one and yet it's filled with critical bugs. We're not even talking performance here but the basics like data corruption bugs, hangs, absurd security flaws, broken APIs, over-complicated file formats, the works. The actual feature spec is fine - whoever designed it at a high level did an OK job - but the implementation is just very poor. It's clear that the devs assigned to it are overwhelmed and seem to lack senior people who can catch basic mistakes during code review. Also even though this subsystem doesn't need high performance they're writing it in C++ instead of .NET, which is certainly making their lives harder. Unfortunately the team is like the polar opposite of the WT team. They don't engage with their user base, only via clueless devrel PM types who can't understand anything they're being told. The relevant systems aren't open source. They don't backport things. They don't communicate. Their docs are flaky, often advertising features that aren't even shipped yet or don't actually work. They make sudden decisions out of the blue that screw their users. Bug reports tend to get met with a stock response asking for submission of logs which are invariably then either "lost" or never heard about ever again.
It's clear that the Windows org has lost the ability to execute. It feels like the start of Atlas Shrugged, where everything is slowly falling apart and nobody can quite put their finger on why. Yet, we are stuck with it. There is a dire lack of competition in the desktop OS space.
Agreed, QA teams have been disbanded and deemphasized as well.
The manager blogging about the new terminal project would often quip about how the team members were younger than conhost.exe. Yes, and it shows. Glad they are learning, but do they not have one old-hand expert at the company to confer with?
Huh? No way was that the first game to implement it. I remember implementing exactly that approach in a simple open source video game in the mid 90s. It was the only practical way to do it with OpenGL1 because textures had to be powers of two in size and you couldn't have all that many of them. I was a very junior/teenage programmer at the time so ended up laying out the glyphs by hand using Paint Shop Pro and then slicing them using glScissor, which was a bad idea because scissoring turned out to be very slow and unoptimized. But it worked. We got text in the 3D engine.
I don't really remember where I got that approach from but very unlikely I came up with it. Most likely it was from GL tutorials.
If I’m not mistaking, the reason why it became a sticking point is because the Alacritty dev had suggested it before Windows Terminal ran into this issue, and they were opposed to it at that point. Is it petty? Honestly, I won’t try to judge that.
The list of "thanks" people is clearly fluff, I don't see the point either. It reads as an excuse to name drop to make the whole thing seem more novel and interesting than it is. Sorry if that's harsh.
There is someone on that list that I wouldn't even want to be associated with to begin with, too. Their conduct in the OSS space is consistently hostile, arrogant and unproductive, and what they're credited for here is not something they themselves even devised or created, so not sure why their inclusion is significant here.
Really strange article.
EDIT: Someone at Microsoft involved with this article has a history of not crediting security researchers, too. Not the author, but someone on Twitter who is clearly involved.
Dunno why but this article really rubs me the wrong way.
EDIT2: Thinking more about it, why wasn't Tyriar of Ansi.js mentioned? IIRC that library was the basis for ANSI rendering in VSCode, at least at one point, and I would imagine WT was heavily inspired by it as Microsoft had a huge interest in it at least as recently as a few years ago - around the time WSL and WT started to get popular.
ANSI.js did a lot right and used hardware acceleration as well. It's just a weird, seemingly random collection of credits...
The backstory is that the idea was suggested on GitHub, where it was rudely dismissed as impossible/inappropriate by the article author, who then tried to implement his preferred solution (with the kernel's text rendering team) and months later came round to the solution proposed on GitHub. Then published this blog post crediting it to "a community member".
The backlash was big enough to make the edit we see today, but if they had written credit and a "literature review" from the start it would have made a better summary of the history of terminal text rendering.
Everything I read online makes me swear off open sourcing stuff. Literally last time this ordeal unfolded on HN people called the dev team out for not thanking people by name and now that they did people think it's fluff?
You've read one sentence and made a conclusion without addressing the rest of my comment. I didn't at all criticize them for citing people. I criticized their choices and reasoning for citing people.
and its a result of reaction to MS devs digging in with such gems like DHowett highly edited responses:
> We get it, Microsoft sucks, we should all be fired, rah rah rah.
> I just don't know what else he's asking for here. Credit? Us to die screaming? The blog post is matter-of-fact, and Casey is right: however, he said himself that it was trivial to do this. Is it not acceptable that we use the same language?
> I'll admit that we didn't list him by name, but neither did we list the other handful of folks involved
> Another day, another Casey post dunking on my team. Hi!
> we apologized
> Casey rightly did not acknowledge it except to tell his followers that it was not a real apology
- You insisted this was a "doctoral research" (your words) and that he was "misguided" (Leonard's words)
- When it turned out he was right, you posted a non-apology (you didn't even name the person you were apologizing to)
- A year later Leonard who claimed it was so hard now writes a blog post that "solution is trivial" and was "suggested by a community member". Once again failing to acknowledge the person who gave you this trivial solution
so MS dev has been forced to finally give credit (but still no apologies), and it only took over a year, multiple edits and little side note blog post update.
I find the comments here a bit sad: some say it's "pointless stuff" and Microsoft should now stop working on WT as it's "good enough", others say "8, maybe 16 distinct colors" are all that's needed.
I just can't agree with that: I want 24 bit colors in my terminal, I want images, I want alpha blending, I want fonts with advanced attributes...
Fortunately, there are a few other people like me. We treasure Windows Terminal (and Foot on Wayland) as in 2022 it is one of the rare terminals that is still evolving and adding features.
Pull requests like this one (#11623) and the work that went behind it (exploring the LUT caching issues) are extremely encouraging: they demonstrate there is still a lot of progress possible, with many low hanging fruits!
Personally, I'm eagerly waiting for Sixel support in WT, until then I suggest https://github.com/csdvrx/sixel-tmux to derasterize sixels and show them even in terminals that don't support sixels.
I don't know if I need 24 bit colors in my terminal, but I agree that being satisfied with such crappy performance when you go a little above "typical" is pretty lame. Software doesn't need to suck, and I appreciate people who want to make it better for better's sake.
One of the reasons the "terminal" (the old console subsystem) stagnated in Windows for so long was that they assigned ownership of it to the same team that owned Explorer (the local one, not IE) and for basically every release up to Windows 8.1 they weren't able to get any budget to improve it. It wasn't until then that people started to realize that the console wasn't just a relic from the past that we would eventually shed, but something that played a serious role in software engineering and IT.
One of the silly limitations it had as a result of this neglect was that it was impossible to run cmd.exe with an arbitrary set of foreground and background colors because it was limited to using a set of 7 unique color schemes stored in the registry. I used to (like 15 years ago) have a hack script for this called colorcmd that would take the fg and bg color hex as arguments. The dirty trick was that the registry keys for the color sets were named for the actual executable that was being run, and I would just make a symlink to cmd.exe called eg colorcmd_RRGGBB_RRGGBB.exe (with the actual rgb hex), create the registry entries for it, then run that exe. Now it seems odd to me to even want many different colors of console (I used to use them for differentiating purpose or project) but that was a fun little workaround at the time.
I 100% agree. It's crazy that terminals haven't really changed since the 80s.
That said I really hope we don't settle for Sixel. It's obsolete and inefficient. We should make a new standard. I think there's enough commonality between 2D drawing APIs (Cairo, Skia, HTML Canvas, etc) that you could easily define a terminal API for one.
> That said I really hope we don't settle for Sixel. It's obsolete and inefficient.
That's a questionable assertion, as some people report watching movies in a terminal with mpv -vo sixel
This is possible because sixels are widely supported, which is the most important part of any format: you can then build on the existing ecosystem and showcase new uses at the same time.
> We should make a new standard
Even if we assume getting everything right on the very first try, the odds of success of starting a new standard + having it supported by the various apps (ex: gnuplot, mpv...) are much lower than having terminals support the existing standard then implementing the new standard in apps / in the terminals.
I was critical of them initially, but when faced with that sort of thing a lot of people will dig in & go into complete defensive mode.
Whether or not that was their initial reaction it takes some effort-- and they did it-- to step back, evaluate, and correct course. It's a credit to them that they were willing to accept the criticism and fix a mistake.
Giving proper credit to community contributors is very important. There are often few perks beyond personal satisfaction for taking the time & effort to help improve projects. Public acknowledgment both validates that effort further and also provides a sort of 3rd party "certification" of it that is a more powerful boost to a Vitae & professional standing than the individual noting accepted pull requests.
Off topic but why do terminal emulators default to what on my computers are illegible colours? With a black background the blue that's picked for folders doesn't have enough contrast to read.
On macOS iTerm at least comes with multiple colour schemes but the default setting is still the impossible to read one.
I agree it's quite annoying. I always redefine the unreadable blue on Mac. It does seem like some platforms (Ubuntu?) have fixed it though based on this table:
By default they mostly don't use black or white, instead using gray approximations, and throwing away monitor contrast and OLED blacks for the background.
Windows terminal is the best thing that happened to Windows since WSL and I hoped it's going to be default soon, because I work with clients that are using W10 but still stuck with cmd.exe, and I have to bypass all their security policy to use cmder so that I have a decent working experience.
Sounds like choosing the wrong environment for the application. A console terminal is for displaying console text. It needs 8, maybe 16 distinct colors. Some might argue it doesn't need colors at all.
So, I want to share a use case. I use a Mac and iTerm. iTerm comes with a nonstandard terminal extension called `imgcat` that allows you to output images, including over SSH. My understanding is basically that it works by passing some special control characters to iTerm itself, who then render an image accordingly. Clearly this is well outside the bounds of what a normal terminal does.
I have a project that involves maintaining an image database of about 15,000 images. The images come from one of three canonical sources, or they can be gathered manually and added. Over time, more data points get added (typically every few years a new batch of a few hundred are added), and manually added images are replaced with canonical images, and canonical images upgrade in quality. I wrote a command line tool that basically allows me to monitor missing images, available upgrades, sources for each image I have, etc.
So, I run my tool, and it says, say, "there is a canonical version of image 12714 available, do you want to replace the current version?". Typically it's going to download both versions, and I'm going to proceed by imgcatting both versions and making a judgment call. This is happening on a remote server than isn't running a windowing system. I make a decision there and it's solved quickly.
Absent imgcat, the workflow is that I maintain a full copy of the database on my local machine, rsync the image directories, use a window manager to open a file explorer and preview both versions of the image, make a judgment call, and then return to the same terminal environment where I tell the same command line application which version to keep. Repeat several hundred times. This doesn't seem like a better workflow to me.
So I guess my question is how do I benefit from my terminal emulator not being able to display images, based on the design I've just told you?
Eh, a true color terminal is significantly prettier with pretty minimal cost. It feels more readable too, but I won't pretend that's the main reason. Why stare at something ugly when you really don't have to?
One wonders why we still find it so important, in 2022, to emulate 1970s hardware in the first place. However, if we're going to insist on tradition hildinng back computing interfaces then we may as well add simple things like 32 bit color.
I really wish Microsoft would stop wasting time on pointless stuff like this. Windows Terminal was sorely needed, but it's now (and has been for 1-2 years) good enough for daily use, and much better than Console Host.
What Microsoft really needs to focus on is PowerShell. PowerShell can't even do basic stuff like piping right, something Bash has been able to do since the 90s:
> Update May 9, 2022: This article was originally published without giving proper credit where it is due. We would like to thank Joe Wilm of Alacritty for establishing modern GPU terminal rendering, Christian Parpart of Contour for the continued support and advice, and Tom Szilagyi for describing the idea previously. Special thanks to Casey Muratori for suggesting this approach and Mārtiņš Možeiko for providing a reference HLSL shader. I deeply apologize to everyone mentioned. Additionally, a wording mistake was corrected in the previous paragraph.
For more background, see https://news.ycombinator.com/item?id=31284419 and https://news.ycombinator.com/item?id=31287647