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

Commands that fill a non-full buffer lock up the terminal for a couple of seconds #444

Closed
Tracked by #1515
Tyriar opened this issue Jan 3, 2017 · 8 comments · Fixed by #445
Closed
Tracked by #1515

Commands that fill a non-full buffer lock up the terminal for a couple of seconds #444

Tyriar opened this issue Jan 3, 2017 · 8 comments · Fixed by #445
Assignees
Labels
area/performance type/enhancement Features or improvements to existing features
Milestone

Comments

@Tyriar
Copy link
Member

Tyriar commented Jan 3, 2017

Perhaps we can prefill/warm up the buffer in a better way?

Steps to reproduce

  1. Run yes

VS Code issue: microsoft/vscode#42234

@Tyriar Tyriar added the type/enhancement Features or improvements to existing features label Jan 3, 2017
@Tyriar Tyriar added this to the 2.3.0 milestone Jan 3, 2017
@Tyriar Tyriar self-assigned this Jan 3, 2017
@Tyriar
Copy link
Member Author

Tyriar commented Jan 3, 2017

Until the buffer is full, calls to syncScrollArea are triggering tonnes of refresh calls.

image

So it looks like this is related to the scroll bar changing (as in #132) which we avoid now when the buffer is full since the scrollbar does not change as the buffer size and scroll position don't change.

@Tyriar
Copy link
Member Author

Tyriar commented Jan 3, 2017

Here's what the non-full buffer syncScrollArea looks like zoomed in:

image

@Tyriar
Copy link
Member Author

Tyriar commented Jan 3, 2017

There's a recursive loop which eventually resolves as terminal data keeps coming in:

  1. Terminal.write
  2. Terminal scroll event
  3. Viewport.syncScrollArea
  4. Viewport.refresh
  5. (repeats from 2)

@Tyriar
Copy link
Member Author

Tyriar commented Jan 3, 2017

Minimal repro: printf 'y%.0s\n' {1..1000}

@Tyriar
Copy link
Member Author

Tyriar commented Jan 3, 2017

It's only recursive because the lines keep changing, refresh should be rate limited.

Tyriar added a commit to Tyriar/xterm.js that referenced this issue Jan 3, 2017
This prevents 1000 scroll events from firing when the buffer is not full

Fixes xtermjs#444
@Tyriar Tyriar reopened this Jan 9, 2017
@Tyriar
Copy link
Member Author

Tyriar commented Jan 9, 2017

Need to redo the PR as there was an issue and it was reverted (#463), the commit is on 444_rate_limit_viewport_refresh

@Tyriar Tyriar modified the milestones: 2.3.0, 2.4.0 Feb 8, 2017
@Tyriar Tyriar modified the milestones: 2.5.0, 2.4.0 Mar 4, 2017
@Tyriar Tyriar removed this from the 2.5.0 milestone Apr 4, 2017
@Tyriar
Copy link
Member Author

Tyriar commented Jun 1, 2018

This is still an issue and a fix would probably involve a custom scroll bar which I'm not sure we want to commit to just yet.

@Tyriar
Copy link
Member Author

Tyriar commented Jul 11, 2018

This is actually only a problem with the way that the attach addon works, as it continually reads in data before the data is parsed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/performance type/enhancement Features or improvements to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant