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