Avoid creating new ArrayBuffers when reducing the size of the buffer

See https://github.com/xtermjs/xterm.js/pull/4109#issuecomment-1243690016

I think we could actually change this:

https://github.com/xtermjs/xterm.js/blob/f9db65c52e4702cf906c14cda1c640342a7b6dca/src/common/buffer/BufferLine.ts#L335-L336

To:

this._data = this._data.subarray(0, cols * CELL_SIZE);

That will keep the same ArrayBuffer, but use a different view of it. We wouldn’t free the memory but maybe we should only do that either when the view is < 1/2 the size of the buffer, or defer the clean up to an idle timeout? It doesn’t make sense to do so many allocations if they’re being thrown away immediately after several resizes.

We could do something similar here:

https://github.com/xtermjs/xterm.js/blob/f9db65c52e4702cf906c14cda1c640342a7b6dca/src/common/buffer/BufferLine.ts#L347-L348

[jerch]

Runtimes w’o zoomlevel madness:

• shrinking ~85ms (~3x faster)
• enlarging within bounds ~93ms (~2.7x faster)
• enlarging out of bounds ~250ms (same speed)

[jerch]

Something weird is going on during enlarging in the demo. If I increase cols by one I get the following onResize dispatching:

Note that I changed cols to 87, which is correctly announce by the first onResize event, but gets reverted by a second event shrinking to 86. Therefore cols in the demo is off by one (stty size also reports 86 afterwards). For some reason the resize dispatching is messed up. It also explains why I see _reflowSmaller above in the profiler stats.

Edit: Oh well, this is a result of updateTerminalSize() in client.ts and FitAddon.fit not yielding the same numbers, if you have a zoom level on the browser (which I had by accident). With zoomlevel 100% I dont get the re-adjustment to cols-1 anymore. So the numbers above are flawed for enlarging (subtract the _reflowSmaller runtime). Not sure if this is worthing being fixed in client.ts, it might create frictions on integrator side, if they c&p the code? (created #4113).