Refterm v2 - Resource usage, binary splat, glyph sizing, and more

Having personally implemented a Unicode text renderer in both DirectX and OpenGL back in 2002 for the Japanese game market, I dare say that chances are that I know a heck of a lot more than you about high performance multilingual text rendering. Don't presume. You just made the exact same argument that Casey Muratori absolutely demolished very publicly. The Windows Console dev team swore up and down that it was somehow "impossible" to render a fixed-width text console at more than 2 fps on a modern GPU when there are "many colors" used! This is so absurd on its face that it's difficult to even argue against, because you have to do the equivalent of establishing a common scientific language with someone that thinks the Earth is flat. Back in the 1980s, fully four decades ago, I saw (and implemented!) colorful ANSI text art animations with a higher framerate on a 33 MHz 486 PC! That is such a miniscule amount of computer power that my iPhone charger cable has more than that built into the plug to help negotiate charging wattage. It's an order of magnitude less than the computer power a single CPU core can gain (or lose) simply from a 1 C degree change in the temperature of my room! You can't believe how absurdly out-of-whack it is to state that a modern high-end PC would somehow "struggle" with text rendering of any sort ! Here is the developers at Microsoft stating that 2 fps is normal, and it's "too hard" to fix it. "I believe what you’re doing is describing something that mi

Oh, this is nothing . Windows force-updated my Notepad.exe to the new modern UI version. It is very visibly laggy for basic actions such as opening menus or scrolling through text. You have to be spectacularly bad at programming to make something so basic so slow in 2022 on a very high-end gaming computer. Not just bad, but utterly oblivious. Casey Muratori excoriated the Windows Terminal dev team for failing to achieve a consistent 60 fps when displaying fixed-width text, which is such a trivial exercise that Casey whipped up a demo in like two weekends. [1] Now the Notepad team insisted on following in the Windows Terminal team's footprints and slowing down the other fixed-width text app that needs to be lightweight fast for all sorts of reasons. Nobody needs Notepad to be pretty. Everyone needs it to work .[2] Just amazing to see something like this happen. It's like a slow motion train wreck, ruining one Windows app at a time. [1] These videos are especially "shocking" because the code he wrote is terse, straightforward, lightning fast, and more correct than whatever madness Microsoft was doing. First weekend: link Second weekend: ▶ this video [2] For example, opening a 300 MB log file takes a solid minute of time, which is absurdly slow. It also bloats this to 800 MB of memory usage. For comparison, TextPad opens it in 5 seconds and uses 30 MB of memory. VS Code, an electron application(!) opens in under 2 seconds.

Replying to my own comment to add the proof that instead of double-digit fps terminal text rendering, he was able to achieve 4-digit fps terminal text rendering after a weekend of coding: Part 1 (Proof of concept): link Part 2 (more features added): ▶ this video

> Layers and layers of cruft which you can trace back to before the computing era. Even those layers and layers don't _have to_ slow things down. Check the refterm "debacle" ([2] for the context, [0, 1] as Muratori's answer to it). It's just the way things are usually programmed doesn't care about performance and how fast things really can be. I sometimes wonder in we're not due for a massive round of optimization on a couple of the layers that we're used to using/depend on. [0] link [1] ▶ this video [2] link

Don't assume. Casey Muratori produced a highly correct Unicode renderer with correct VT code support. Watch the video: ▶ this video

This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all. The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal! RefTerm 2 vs Windows Terminal in action: ▶ this video Refterm 2 source: link One of the previous discussions: link [1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.

It's been slow like this (and with lots of user complaints!) since always! Perhaps you guys should borrow some of those Microsoft research phd folks to improve terminal performance[1]. [1]: ▶ this video

For reference, I've never seen the built-in Windows VPN protocols exceed ~70 Mbps in any scenario. Maybe it's possible with a crossover cable between two Mellanox 100 Gbps NICs, using water-cooled and overclocked CPUs, but not over ordinary networks with ordinary servers. I have gigabit wired Internet to a site with gigabit Internet. Typical performance of SSTP or IKEv2 is 15-30 Mbps. That's 1.5% to 3% max utilisation of the available bandwidth, which is just... sad. It's not the specific site either, other vendor VPNs can easily achieve > 300 Mbps over the same path. It's a year and a half into the pandemic, there are record numbers of people working from home, and Microsoft is the world's second biggest company right now. Meanwhile, volunteers put together a protocol in their spare time that is not only more secure but can also easily do 7.5 Gbps! That needs to be repeated: At least ONE HUNDRED TIMES faster than the "best" Microsoft can offer to their hundreds of millions of enterprise customers that are working from home. Someone from Microsoft's networking team needs to read this, and then watch Casey Muratori's rant about Microsoft's poor track record with performance: ▶ this video

You should look into Casey Muratori's quest[1] against Windows terminal slowness on github and youtube. There were some heated exchanges there and some proof of concept software created to demonstrate both how slow Windows Terminal is, and how fast a GPU enabled terminal can be. [1] The latest video for it is here: ▶ this video

In his follow up video[0], he shows that in-use-memory is half that of Windows terminal, whilst simultaneously being >100x faster. Windows terminal chugging away in the background consuming 20% CPU for minutes at a time whilst he's debunking these claims / running the same data on refterm a few times over is hilarious (inflammatory or not). 0. ▶ this video