How fast should an unoptimized terminal run?

Sure.

> Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.

They really are missing several important things. For example, DirectWrite and similar APIs are optimised for all possible scenarios, including really obscure ones such as text with arbitrary transformations applied to it. Similarly, it can handle smoothly animating the size or position of the text, and can do so to subpixel accuracy. This is useful for making web browsers or flashy GUIs, and is unnecessary complexity for a terminal emulator, which in all practical cases renders fixed-width text aligned to a uniform grid. This really is trivial, and the Microsoft developers lost sight of this. It's easy to just assume that optimisation is impossible if you believe that the problem is too hard to optimise. They're wrong.

> it lays down glyphs in your "texture", by using a backing glyph atlas internally already. Basically the thing you suggest us to do, is already part of the framework we use.

Almost certainly it'll be sending one or more commands to the GPU per "glyph run". This is a well-known issue in game programming circles, and the solution is to bend over backwards to batch your calls. E.g.: sorting the characters into identical colours and drawing those all together in a single call can be faster than the naive left-to-right order. Ideally, you want create a texture (or two) with the colours, and use that as an input into a shader when drawing all of the characters in one go.

> DirectWrite doesn't necessarily cache glyphs between renderings.

That's silly.

> when the problem you have is caused by the number of calls and not the complexity to layout a couple ASCII letters.

So then they are aware of the problem with the number of draw calls. So why not optimise it?

> Also ClearType can't be trivially alpha blended making it impossible to render into a separate glyph atlas.

Not exactly true, and definitely not true if you rethink your rendering approach. E.g.: store horizontally stretched glyphs and then scale them down, finalising the ClearType in a pixel shader as the final step. As a bonus, this would make some special cases render more accurately. Also note that unlike the general-purpose case, terminals don't need every possible subpixel alignment, since the glyphs are always aligned to a regular grid.

> this is something WT will probably do as well in the future

No, it won't. Windows Terminal has been in development for years already, and clearly they haven't thought about performance at all, or even bothered to eliminate unnecessary std::string operations in their inner graphics loops, which is clownshoes.

This is what it boils down to: a typical terminal shows 130x100 = 13000 characters in its viewport, which is a uniform two dimensional rectangular grid. Updating this is simply a matter of drawing different content in those cells. That's it. In terms of graphics complexity, this is hilariously trivial. You can easily get hundreds of frames a second in pure CPU code. This is a task that doesn't even require advanced instructions like division.

The lack of performance as an aspiration is certainly part of the problem, but it also feels like there is a certain level of lack of intuition for the subject matter. If they believe that they are doing great and you’d need a full PhD dissertation to improve, and they 1000x below the base expectation of what someone can do in 2 days without even doing basic profiling and optimization. Then the problem is deeper than not valuing performance, it also speaks to a team that severely lacks an awareness of what they are working with.

I feel like this is similar to situations I have seen where people “explain” why database queries take several minutes to return with excuses like “that makes sense because we have years worth of data stored in the database” when in reality it’s because someone doesn’t understand how a composite index works. Someone who has a bit of intuition for db’s instantly knows something is wrong, but if your team lacks anyone with that intuitions, your team will spend their time finding “explanations” for the bad performance instead of fixing it.

Try in st, for me it's much faster than xterm.