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

Smooth scrolling #1140

Closed
baukevanderlaan opened this issue Dec 11, 2017 · 17 comments
Closed

Smooth scrolling #1140

baukevanderlaan opened this issue Dec 11, 2017 · 17 comments
Assignees
Labels
area/mouse-support type/enhancement Features or improvements to existing features
Milestone

Comments

@baukevanderlaan
Copy link

As someone who’s new to working with CLI’s I find it cognitively harder to view the line by line scrolling used in terminals as opposed to the smooth scrolling of most other applications. I learned that it’s because in a terminal, the character and not the pixel is the smallest display unit.

Is it possible (and desirable) for xterm.js to work around this and incorporate a smooth pixel-based scrolling option?

I originally asked @albinekb the same thing for Hyper (https://github.com/zeit/hyper) and he referred me to this project since Hyper uses xterm.js.

@Tyriar
Copy link
Member

Tyriar commented Dec 11, 2017

It's certainly possible to do but it would be quite a lot of work (+added complexity) for something that so few people would use. I'd prefer not to add this personally.

@baukevanderlaan
Copy link
Author

That's understandable and fair. Thanks for your work!

@egmontkob
Copy link

FYI: VTE (GNOME Terminal and friends) does this since version 0.44. (Of course it only works in the scrollback of the terminal emulator, not when e.g. scrolling the file in a text editor.)

@egmontkob
Copy link

egmontkob commented Dec 17, 2017

something that so few people would use

Everyone who scrolls with the touchpad uses it in VTE, whether they like it or not :D

@Tyriar
Copy link
Member

Tyriar commented Dec 18, 2017

@egmontkob I have gnome terminal 3.18.3 here and it doesn't seem to work, the scrolling section in profile settings also doesn't seem to have a setting?

screen shot 2017-12-18 at 6 57 19 am

@egmontkob
Copy link

g-t 3.18.3 most likely means you have vte 0.42, whereas this feature is new in 0.44.

No new setting (there's a pending low-prio request to add one), it just behaves different than before.

@egmontkob
Copy link

Someone already expressed their dislike about this not being configurable in VTE. Of course it's totally your choice whether you implement this feature at all in xtermjs, and if you do, whether you make it configurable.

I think it could be a precious data point for you that this feature has been there in VTE for more than 1.5 years now, and "forced" on all VTE users who use a trackpad (rather than mouse wheel which sends "units" of scrolling for which we still scroll entire lines), and during these times I heard 2 or maybe 3 complaints in total to bring back the old behavior. If this feature sucked, there'd be much more complaints.


I don't have usage numbers or ratio about VTE, the closest I have is the results of this poll (note that the date of the article is mangled, based on the comments' timestamps it's a 2 year old vote) which suggests that VTE's market share among Linux terminal emulators is in the ballpark of 50%, that is, pretty big. So plenty of folks out there already use smooth scrolling.


I'm new to xtermjs and friends and I haven't tried it yet, just see that cool things are happening here. I'm not sure I have the right architecture in my mind, but if I do then GNOME Terminal is to VTE what hterm is to xtermjs. VTE is a GTK+ widget doing terminal emulation. There are around a dozen more or less popular terminal emulator apps using VTE, including GNOME Terminal, Xfce4 Terminal, Terminator, Tilix...


In case you'd like to try out the behavior, the easiest way (for this, as well as any VTE features that don't require cooperation from GNOME Terminal) is to compile VTE only and start its test app:

  • Get from git or tarball
  • ./autogen.sh (git) or ./configure (tarball)
  • make
  • ./src/app/vte-2.91 (from 0.51) or ./src/testvte (up to 0.50) or ./bindings/vala/vte-2.91 or ./src/vte-2.91 (up to 0.50, got moved to another directory at some point)

@Tyriar
Copy link
Member

Tyriar commented Jan 2, 2018

I was using the mouse wheel, that's my problem 😅

@baukevanderlaan
Copy link
Author

In the initial post I forgot to mention the quite important detail that I use a trackpad indeed. Disregarding trackpad users or users of other touch-based input methods, I understand that few people prefer pixel-based scrolling.

@Tyriar Tyriar added type/enhancement Features or improvements to existing features and removed type/feature labels Apr 4, 2018
@Eugeny
Copy link
Member

Eugeny commented Nov 28, 2018

IMO it's safe to say that it's just expected by the users at this point. I mean, even hterm has it.

@Tyriar
Copy link
Member

Tyriar commented Nov 28, 2018

It's not really possible with the canvas renderer, however it will should be fairly easy to accomplish with the webgl renderer #1790 that should replace the canvas renderer. For the DOM renderer we can achieve this by having partially visible lines on the top and the bottom. As such, I consider this blocked on #1790

Something else to consider: having ydisp not be an integer and having more than rows than Terminal.rows visible breaks some assumptions made in code, for example how does it affect screen reader support?

@sdegutis
Copy link
Contributor

sdegutis commented Dec 5, 2019

It's not really possible with the canvas renderer

Why not? It should be as simple as drawing viewportHeight + 2 number of rows, and offsetting somewhere between the first and second row based on the current scroll position's pixel-offset.

@sdegutis
Copy link
Contributor

sdegutis commented Dec 5, 2019

It's certainly possible to do but it would be quite a lot of work (+added complexity) for something that so few people would use. I'd prefer not to add this personally.

Fwiw I was going to request the same feature. I personally think it's an important step towards increased usability. The fact that it's not more widely supported could be explained by the fact that it's a relatively new idea, and that we programmers tend to just get used to the limitations we have to work with.

@Tyriar
Copy link
Member

Tyriar commented Dec 5, 2019

Why not?

@sdegutis yeah it is possible, back then I was thinking that the canvas renderer would be highly optimized by using special logic to only invalidate sections of the content that needed it. Scrolling the terminal now with the canvas renderer will re-render all the rows anyway, plus even though it's the default the plan is to phase out the canvas renderer anyway.

It should be pretty easy to get this going, it's just it needs to be done for 3 renderers and webgl in particular will need some special tweaks (increasing the size of the attribute buffer since there are more cells drawn than rows * cols).

@musm
Copy link

musm commented Jun 4, 2020

I'd also love this feature, my issue is actually not simply aesthetics, it's a usability problem. The issue is that one action, causes way too many skips on the terminal and the fact that there's no smooth scroll makes it almost impossible to understand what lines were skipped over. It really makes the terminal hard to use.

@PoetaKodu
Copy link

Every time I scroll the terminal in Visual Studio Code I lose track of where I've been. Smooth scrolling is a basic feature and we need it.

@Ashesh3
Copy link

Ashesh3 commented Jan 22, 2022

Same here, it's hard to scroll in vscode terminal. Please consider this feature.

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

No branches or pull requests

8 participants