3 ms·

> 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 an

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

kragen 4y ago
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 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-shell.c 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!
deleted 4y ago
[deleted]
salawat 4y ago
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.

kragen 4y ago

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

deleted 4y ago

[deleted]

salawat 4y ago

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.