5 ms·

The mentioned GitHub issue: https://github.com/microsoft/terminal/issues/10362 https://github.com/microsoft/terminal/issues/10362

• vanderZwan 5y ago
  So can anyone knowledgeable regarding text rendering comment on the last comments there?
  • jiggawatts 5y ago
    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.