[EPILEPSY WARNING] How fast should an unoptimized terminal run?

What people said

dundarious · 2022-05 · Strong recommendation

Worth watching Casey Muratori's series of videos on terminals, and how to implement them, where he often makes specific comparison to Windows Terminal. He has some specific criticisms that are easy to disagree with, but the vast majority are well warranted. His broader series of videos on the topic are even worthwhile from a purely "software engineering education" standpoint. [VIDEO] I feel a bit bad about posting comments about it relatively frequently on HN, but it's just so very very good, and snark aside, his perspective is extremely valuable.

Read the original HN comment ↗

dmitriid · 2021-07 · Strong recommendation

As luck would have it, here's the continuation to Windows Terminal. Casey Muratori made a reference terminal renderer: [LINK] This uses all the constraints that the Windows terminal team cited as excuses: it uses Windows subsystems etc. One person, 3k lines of code, it runs 100x the speed of Windows terminal. See the epic demo (and stay till the end for color output): [VIDEO]

Read the original HN comment ↗

jodrellblank · 2025-07 · Recommendation

It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project". In response, Casey spent <1 week making RefTerm, a skeleton proto-terminal with the same constraints Microsoft people had - using Windows APIs for things, using DirectDraw with GPU rendering, handling terminal escape codes, colours, blinking, custom fonts, missing font character fallback, line wrap, scrollback, Unicode and Right-to-Left Arabic combining characters, etc. RefTerm had 10x faster throughput than Windows Terminal and ran at 6-7000 frames per second. It was single-threaded, not profiled, not tuned, no advanced algorithms, no-cheating by sending some data to /dev/null, all it had to speed it up was simple code without tons of abstractions and a Least Recently Used (LRU) glyph cache to avoid re-rendering common characters, written the first way that he thought of. Around that time he did a video series on that YouTube channel about optimization and arguing that even talking about 'optimization' was too hopeful, we should be talking about 'not-pessimization', that most software is not slow because it has unavoidable complexity and abstractions needed to help maintenance, it

Read the original HN comment ↗