Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scrollback doesn't work as expected #361

Closed
Tyriar opened this issue Nov 16, 2016 · 4 comments
Closed

scrollback doesn't work as expected #361

Tyriar opened this issue Nov 16, 2016 · 4 comments
Labels
type/bug Something is misbehaving

Comments

@Tyriar
Copy link
Member

Tyriar commented Nov 16, 2016

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.

@Tyriar Tyriar added the type/bug Something is misbehaving label Nov 16, 2016
@Tyriar
Copy link
Member Author

Tyriar commented Nov 26, 2016

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:

  • There's a weird bitwise or which I believe does nothing (| 0)
  • A chunk of rows is cut off when scrollback is reached
  • Why is the trimming of the lines being done on scroll, shouldn't it be done when this.lines is appended to?
  • The slice may cause performance issues as it produces a new array and discards the old one

What 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.

Tyriar added a commit to Tyriar/xterm.js that referenced this issue Nov 27, 2016
@Tyriar
Copy link
Member Author

Tyriar commented Nov 28, 2016

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

@parisk
Copy link
Contributor

parisk commented Dec 8, 2016

@Tyriar I'd be happy to do some testing on your branch and provide feedback if you think the timing is 🆗 .

@Tyriar
Copy link
Member Author

Tyriar commented Dec 8, 2016

It's a little too broken currently, will have to find some time to finish it off

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug Something is misbehaving
Projects
None yet
Development

No branches or pull requests

2 participants