It appears that the total buffer size wants to be <viewport rows> + <scrollback>, however when I hook it up in vscode to be 10, I notice that the amount of scrollback provided is not 10 and seems to alternate between 2 values.
Running ll to get a chunk of output, I get 6 lines of scrollback the first time, 8 the second time, 5 the third, 7 the fourth, etc. It should be exactly 10 every time.
This seems to be happening because of this logic in scroll:
if (++this.ybase === this.scrollback) {
this.ybase = this.ybase / 2 | 0;
this.lines = this.lines.slice(-(this.ybase + this.rows) + 1);
}
Here are a few observations/questions:
| 0)scrollback is reachedscroll, shouldn't it be done when this.lines is appended to?slice may cause performance issues as it produces a new array and discards the old oneWhat if instead of this model where Terminal.lines is continuously being rebuilt, we implement a circular array and abstract the complexity away inside a class? So an array is always of size Terminal.rows + Terminal.scrollback, meaning there is no array reconstruction or shifting (which can have issues on sufficiently large arrays) and scrollback is handled for us as old array entries will be overridden.
It would probably be even better to just use Terminal.scrollback, that way Terminal.lines would only ever need to be resized when Terminal.scrollback is changed (as opposed to when Terminal.rows changes also). That's a change from the current model though, it might be good to change the setting to bufferSize or bufferLength if we do this.
I have a WIP branch that implements this new model using a CircularList class, it's not working 100% yet and I'm going to put it on hold for now to focus on some other stuff. https://github.com/Tyriar/xterm.js/tree/361_circular_list_scrollback
@Tyriar I'd be happy to do some testing on your branch and provide feedback if you think the timing is 馃啑 .
It's a little too broken currently, will have to find some time to finish it off