4 ms·
The notable update is: > Update May 9, 2022: This article was originally published without giving proper credit where it is due. We would like to thank Joe Wil
by peter_l_downs 4y ago
The notable update is:
> 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 https://news.ycombinator.com/item?id=31284419 and https://news.ycombinator.com/item?id=31287647 https://news.ycombinator.com/item?id=31287647
- cyber_kinetist 4y agoBTW, 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: - https://docs.cocos.com/creator/2.4/manual/en/advanced-topics/dynamic-atlas.html https://docs.cocos.com/creator/2.4/manual/en/advanced-topics... - https://github.com/mattdesl/gl-sprite-batch https://github.com/mattdesl/gl-sprite-batch - https://github.com/RandyGaul/cute_headers/blob/master/cute_spritebatch.h 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".
- jchw 4y agoIf 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.
- aliswe 4y agoHe didn't claim it was anything else than straightforward, though, which is why he got frustrated that the idea was dismissed, afaik: https://twitter.com/cmuratori/status/1523028039705055234?t=x91IgzTwhhONjrz8dwSApg&s=19 https://twitter.com/cmuratori/status/1523028039705055234?t=x...
- curiousgal 4y agoWho knew proposing good ideas in a condescending manner would lead to them getting dismissed! I'm shocked! /s
- native_samples 4y agoNot 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.
- junon 4y agoThe 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...
- curiousgal 4y ago> The list of "thanks" people is clearly fluff 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.
- junon 4y agoYou'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.
- lozenge 4y agoThe 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.
- CodeArtisan 4y agoOP article says >"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.gamerwithin.com/?view=article&article=1319&p=1 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-technical-marvel/ https://www.pcgamer.com/remembering-rage-a-flawed-but-techni...
- native_samples 4y agoHuh? 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.
- junon 4y agoAlacritty was far from the first hardware accelerated terminal emulator.
- rasz 4y agoand 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 TLDR for people not in the loop: https://news.ycombinator.com/item?id=31285123 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.