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

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. [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: [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: [VIDEO]

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

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

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]: [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: [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.

> 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] [VIDEO] [2] [LINK]