Comment by naikrovek | Hacker News Reader

Comment by naikrovek | Hacker News Reader

Parent Full thread

> It seems perfectly fair to expect Microsoft to throw resources at heavily used apps.

yes it does seem perfectly fair, doesn’t it? it isn’t. the amount of work that needs to be done always outscales the ability to do the work, forcing prioritization. the Windows Terminal team is not large, and just throwing people at the team will not make it faster.

> "They don't have the experience to make it good" is pretty chickenshit.

you’re very unpleasant already. second sentence, calling me chickenshit. classy.

how many people do you know who are capable of writing what Casey wrote in two weekends who also DON’T work on games full-time?

i don’t know any people like that. so, where do you think those people go to work? on Windows Terminal? like that’s a common career path for someone like Casey? i would be absolutely flabbergasted if there were someone on the Windows Terminal team who knew how to do what Casey did before he did it. “Hey, come work on the command prompt” does not attract people who understand how to dynamically generate a texture atlas of code points and use that atlas to render a texture representing the console window contents 60/120/144/240 frames per second. the people that know how to do that are already spoken for.

> i would be absolutely flabbergasted if there were someone on the Windows Terminal team who knew how to do what Casey did before he did it.

THAT is precisely the problem!

What Casey did was not some unique and special solution known only to dark wizards working on AAA game engines.

It's an obvious solution that has been implemented many times before by many people for many systems. All green-screen and DOS-era terminals work this way, for example.

Admittedly, I'm a former game engine developer, but I went into that career with essentially zero industry experience of any type. I just muddled my way through a C++ textbook and started writing a game engine.

I needed a text console for my game engine, and I also needed to display Unicode text because we were targetting an international market.

Completely naively I wrote a "text engine". It took about a week, and my solution was virtually identical to Casey's. The difference was that I was slower at implementing it, and Casey's is more feature complete, but the approach was identical.

I didn't go to Hogwarts School for Game Development Wizardry. I just thought about the problem and applied the obvious solution.

The difference between people like Casey and the Microsoft team is not necessarily aptitude, but attitude. The Microsoft team has no mechanical sympathy and no interest in quality.

They made arguments not just along the lines of "this is impossible", but also "nobody needs this".

Through every fibre of their being they believe that computers are slow and that this is fine.

> All green-screen and DOS-era terminals work this way, for example

lol no they do not. absolutely not lol

> The Microsoft team has no mechanical sympathy and no interest in quality.

I know people at Microsoft. I have acquaintances on the Windows Terminal team. this is just plain factually incorrect.

The proof is in the putting sadly. Anyone with a concern about Quality would not have shipped. As they would be inflicting pain rather than resolving it.

Green-screen and DOS-era terminals don't work by having a custom shader running on a GPU, it's true, but they do have hardware that does the same thing Muratori's custom shader does: generate screen pixels by looking up texture data in a texture atlas indexed by a glyph index taken from a display buffer, which is updated by software. Consequently their display latency averages about 9 milliseconds.

Those character generators don't do rescaling and linear interpolation of the texels, and often they're only one-bit color, but that's extra work refterm is doing that DOS-era terminals weren't doing. It wasn't that Muratori invented a new, more efficient way to do things; he just reproduced the bitmap character-generator approach that was standard from 01975 to 01985, but runs it on faster hardware. So he got about 160 megabytes per second before optimizing, ten times faster than Windows Terminal, and 1600 megabytes per second after he "put in the most basic optimization [he] could think of".

It isn't necessary to do character generation on the GPU to be responsive, either. The Alto running Smalltalk took maybe a second for its ≈0.5 MIPS CPU to redraw a screenful of proportional text, say about 2kB. The original Macintosh took maybe 100 ms using a 1-MIPS CPU and hand-optimized assembly. But the laptop I'm typing this on is about 34000 MIPS so it ought to be able to do the job in ≈3 μs. My word-wrapped proportional-font experiment in http://canonical.org/~kragen/sw/dev3/propfont.c gets 72 MB/s, which works out to ≈30 μs per 2-kB "screenful". Valgrind says it's running about 113 instructions per byte rendered, suggesting my C is closer to Smalltalk performance than QuickDraw. It's still 20× as slow as refterm but it's not using the GPU, but 5× as fast as Windows Terminal. (On the other hand, it doesn't draw to the actual display, just a memory buffer which it outputs to a PNM file at the end.)

My own unoptimized monospace terminal emulator running on the CPU with a full-color font https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-s... takes 6.9 wallclock seconds and 3.1 CPU seconds to display the output of yes {1..90} | head -c 1000000. This is enormously slower, only 145 kilobytes per second or 323 kilobytes per CPU second, a whole 14 milliseconds per 2-kB screenful. (And its screen really is 2 kB.) This is 1000 times slower than refterm and 100 times slower than Windows Terminal, and it still doesn't handle the difficult cases like combining characters, double-width CJK characters, and RTL text. Probably I should optimize it!

I didn't call you chickenshit, I called giving them leeway chickenshit (by synthesizing a statement that I thought roughly reflected the leeway).

I have no idea who could match what, but Windows is just an utterly massive product, they have the resources to make the whole thing shine, even if people really don't want to work on it and need big bribes.

Casey wrote code and made it public. That is helping.

Regardless, this isn't about Casey. This is about MS releasing crap software. Text editors from 30 years ago were faster than WT. Something is horribly broken about the programmer's approach to writing code, or they are being horribly managed, or all of the above.

On the surface, it often feels like there is just an extreme lack of pride in workmanship. In code from lots of vendors I am constantly seeing interfaces with strange glaring issues, with bizarrely convoluted UI paths, with odd render bugs, etc... It feels like there is something unfortunate happening across the industry. Maybe I'm just a cranky older engineer, but seeing so many visual and functional failures being shipped makes me think the issue is far deeper than that.

Reply on news.ycombinator.com