How many colors are too many colors for Windows Terminal?
devblogs.microsoft.com
devblogs.microsoft.com
> 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
- https://docs.cocos.com/creator/2.4/manual/en/advanced-topics...
- https://github.com/mattdesl/gl-sprite-batch
- https://github.com/RandyGaul/cute_headers/blob/master/cute_s...
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".
https://twitter.com/cmuratori/status/1523028039705055234?t=x...
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.
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?
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...
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?
This is why we can't have nice things.
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.
I invite everyone to go through the actual discussion[0] and draw their own conclusions.
Whether or not one is correct doesn't really matter when you don't give the maintainers much reason to engage with you.
HN: They should credit Casey
Microsoft: Credits Casey and several authors
HN: The credits list is clearly fluff.
Never change, Internet.
>"Instead of drawing 1000 glyphs into 1000 tiny textures, we’ll just allocate one huge texture and subdivide it into a grid of 1000 glyph cells."
that's the same as John Carmack's MegaTexture. First game to use it was Enemy Territory: Quake Wars (2007).
Him talking about the concept back in 2006:
https://web.archive.org/web/20060901185133/http://www.gamerw...
Rage originally used 1TB of texture that had to be reduced to 20GB for the release version:
https://www.pcgamer.com/remembering-rage-a-flawed-but-techni...
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.
> 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
TLDR for people not in the loop: https://news.ycombinator.com/item?id=31285123
- You and lhecker insulted Casey Muratori
- 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 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.
If you find such things interesting, check https://github.com/dankamongmen/notcurses/issues/1223 and the notcurses project: a great introduction is https://www.youtube.com/watch?v=b4lmMADP1lA
Adding features adds possibilities.
Nobody will force you to use them.
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'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.
Sixels exists and can be used right now.
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.
On macOS iTerm at least comes with multiple colour schemes but the default setting is still the impossible to read one.
https://en.wikipedia.org/wiki/ANSI_escape_code#3-bit_and_4-b...
Does windows terminal use the same colors?
Some might argue it doesn't need letters either.
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?
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:
But i agree that it's almost embarrassingly bad, that native piping has had no significant progress since 2016.
With PowerShell Core (7.x) now in a good state, one would think the piping could be improved.
Do note that it is targeted for PowerShell 7.3 tentatively, so it won't be used by default in Windows 10/11 or Windows Server.