Looks like Microsoft finally found someone good enough at terminal emulator development to fix the performance issues.

I can't shake the feeling that the original Github issue and the heated discussions in there were more Windows Terminal devs not wanting to admit their knowledge gap in this area than impracticality and complexity.

To be fair, the GitHub commenter in question had made this statement:

> It really seems like most of the code in the parser/renderer part of the terminal is unnecessary and just slows things down. What this code needs to do is extremely simple and it seems like it has been massively overcomplicated.

I think they deserved a better response from Microsoft, but I also probably would not have responded favorably to that wording – irrespective of if they were correct.

>most of the code in the parser/renderer part of the terminal is unnecessary and just slows things down. What this code needs to do is extremely simple and it seems like it has been massively overcomplicated

He means exactly what he says. Notably, refterm had almost no optimization applied to it.[0] The massive performance increase was entirely due to non-pessimization.[1]

>refterm actually isn't very fast. Despite being several orders of magnitude faster than Windows Terminal, refterm is largely unoptimized and is much slower than it could be. It is nothing more than a straightforward implementation of a tile renderer, with a very simple cache to ensure that glyph generation only gets called when new glyphs are seen. It is all very, very simple. A more complex codebase that parsed Unicode and rendered glyphs itself would likely be much faster than refterm for many important metrics.[0]

[0] - https://github.com/cmuratori/refterm

[1] - Refterm Lecture Part 1 - Philosophies of Optimization - https://www.youtube.com/watch?v=pgoetgxecw8