Atlas performance

[WaitingForGuacamole]

So, new experimental text renderer - great! I also read the release note from @cinnamon-msft that performance differences were likely to be negligible at the moment, - noted. Decided to test it out with a simple use case anyway.

TL;DR - no meaningful performance change at all, which is not unexpected, but it led me to an interesting observation about shells and WSL.

My setup: Core i9-10750K, 64GB RAM, 2TB Samsung 970 EVO Plus SSD, RTX 3080 GPU, on Windows 22H2, build 22581.200.

Test: Create a 10MB text file in my Windows home folder. Replicate that file into the home folders of two Linux WSL distros. Time how long it takes to dump that text file to the console in Powershell 7.2.2, Ubuntu 21.10, Fedora 36, and CMD.

Measurement: Not terribly precise, but at least internally consistent. Powershell, using oh-my-posh with execution time wired into the prompt. Fedora and Ubuntu, using time command in zsh. CMD, using %time% bookends and some calculation.

With Atlas off (all times in seconds):

Powershell 7.2.2: 21.581 21.587  21.753
Fedora 36:         1.572   1.568  1.570
Ubuntu 21.10:      1.577   1.584  1.593 
CMD:              11.490  11.650 11.170

With Atlas on (all times in seconds):

Powershell 7.2.2: 21.789 21.470 21.611
Fedora 36:         2.217  2.176  2.208
Ubuntu 21.10:      2.129  2.132  2.137
CMD:              11.240 11.000 11.120

Summary: Atlas hasn't yet changed performance, which is predicted. It also seems pretty stable this far, which is a win. The real takeaways for me were 1) how slow Powershell is to this day in console performance, and 2) how fast Linux consoles can be in WSL2!

Look forward to seeing more in this area!

[zadjii-msft]

I believe @lhecker has been preparing a blog post on the topic for quite some time now, so he's probably interested in this discussion. We've still got plenty of enhancements in the works, so stay tuned!

[lhecker]

If Direct2D/D2D (which is what the old renderer is based on) was actually slow and we could just write something much faster within a few months, it'd be a pretty poor outlook for Microsoft's engineering. 😅

D2D implements text rendering using a built-in glyph/texture atlas to cache rasterized glyphs and a lookup-table/LUT for coloring those glyphs. I'm not sure about the size limit for the glyph atlas, but the LUT has a limit of about 20 colors. This works fine for almost all situations (even this website, GitHub, doesn't use >20 text foreground colors), but if you exceed this, an excessive amount of time is spent updating the LUT, causing a steep drop in performance. Again, this isn't much of a problem for Websites and other UI applications, since the text will be mostly static, but for Terminals we routinely see applications coloring their entire background in ░▒▓█ block characters, animating text at >60 FPS, etc., where this starts to be an actual problem.

Our new renderer is specifically written for modern hardware and for monospace text only, which means it can both drastically simplify the implementation, assuming that each character is drawn in a fixed grid (unlike with regular, proportional fonts, D2D has to support) and take advantage of today's GPUs with their performant calculations and relatively large memories.
D2D was written when DirectX 9 was still the most modern API. I'm pretty sure this new engine would both use more power and be slower on such old hardware than D2D, because it runs so many calculations on each pixel to correctly colorize glyphs. D2D on the other hand uses the LUT to drastically reduce the necessary computations. On modern hardware however those calculations aren't much of a problem anymore. Not even branches/if-conditions can faze it much.

The end result is that you should find that the newer atlas engine will draw less power on modern GPUs like your RTX 3080 (specifically DirectX 11 and newer GPUs). On slower, portable hardware, you should see an actual improvement in throughput. On my laptop for instance I see an improvement of about 15%.

Basically you can't notice this performance improvement, because your PC is simply too fast. 😄
I think we'll see the performance improvements from this newer engine even on faster hardware like yours, once we improve the performance of our text buffer, which right now consumes about 10x the CPU compared to the text renderer, when ingesting text. Since the relative CPU usage of the text renderer will then be greater, the relative difference between the old and new engine should be more obvious.

But as I said initially, the most noticeable improvement right now can already be observed with highly colored and/or complex text. I recorded a video of such a TUI application a while ago:

NL6uL25ugufkPPpt.mp4

[steve-down]

Leonard, thanks very much for the detailed perspective. It's fascinating to consider in this day and age that that text rendering could still use performance overhauling! I mean, it makes sense in light of your explanation, especially the idea that at some point, hardware might mask differences in performance.

For me, I'm just glad that performance is taken seriously in a tool that's rapidly become a basic necessity! In truth, though, my little exercise was just as revealing of how performant WSL has become, which is also impressive.

[steve-down]

So, I remade my test workload as follows: 1) created about 30,000 words of Bacon Ipsum text, 2) wrote a Powershell script to randomly colorize the text with ANSI color codes (8-bit).

Now, I can't compare apples-to-apples with my previous comparison because the updated workload is much larger, but now my Linux test is about 14% slower with Atlas on, but Powershell is about 21% faster!

Atlas	Executor	Run 1	Run 2	Run 3
On	Powershell 7.2.2	91.534	92.011	128.639
On	Ubuntu 21.10	56.860	56.883	56.540
On	Fedora 36	57.689	55.776	55.931
Off	Powershell 7.2.2	115.010	117.878	118.779
Off	Ubuntu 21.10	49.848	49.717	50.029
Off	Fedora 36	50.702	50.267	51.302

I've attached my sample data and script if it's of any interest. Note that I'm not saying anything is wrong, or that anything needs doing on the basis of this. I just find it all pretty fascinating.

BaconIpsum.zip

[ebresie]

I wasn't sure where to provide my experience, so this seemed like a possible place, but if I'm misunderstanding and maybe this should be captured elsewhere, please don't hesitate to point me in the right direction.

I've been following along on a few different places regarding Window Terminal rendering and believe I may have had some performance impacts when trying to use a git bash shell which includes assorted colored text within.

From Settings...Rendering, there are listed two options like the following

Both of these options were disabled. When I enable both of these options, the rendering seems to work much better with much reduced lags between pressing keys and rendering in the given terminal.

I've tried this on 1.12 and the 1.13 preview release for which each seems to work similarly.

Not sure this is related to any recent updates or renders but I could be wrong. Am I missing something?