Terminal: Font size updates get slower the bigger the font

[aeschli]

Testing #158827

Version: 1.71.0-insider
Commit: bd61073
Date: 2022-08-23T05:19:02.563Z
Electron: 19.0.12
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin x64 21.6.0
Sandboxed: Yes

• set setting terminal.integrated.gpuAcceleration: on
• in the terminal type (not sure the text really matters)

echo -e "\x1b[4:3m"  # curly underline
echo -e "\x1b[4:4m"  # dotted underline
echo -e "\x1b[4:5m"  # dashed underline

• open the settings (I used the settings JSON) and change the font size, save the settings after the changes
• note that the terminal propertly updates to the new font size, but the bigger the font is chosen (e.g. 30), the slower the update gets, until things get stuck and only parts of the terminal get updated

[aeschli]

Once you scroll or type, the terminal is refreshed and rendered with the proper font size

[Tyriar]

This is currently expected, we use a single 1024x1024 texture currently which gets warmed up with some ascii and whatever is displayed in the canvas. When the texture gets filled it is cleared and restarted. In practice I don't think anyone ever hits this, it's much more likely on a high DPI display though.

We could support multiple textures (~4mb GPU memory each), but that would involve some feature work in xterm.js

[Tyriar]

Upstream: xtermjs/xterm.js#4061

[aeschli]

Once I scroll, all looks fine again. So this looks like a refresh issue?

[Tyriar]

It will always get slower as the larger the text, the more that needs to happen. But we now support multiple texture atlas pages that merge and increase in size which is not only faster to upload to the GPU but essentially gives us unlimited texture space for glyphs.

We should never hit the broken looking viewport now.