Xterm.js: Smooth scrolling

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.

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

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

something that so few people would use

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

@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?

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.

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)

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

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.

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

It's not really possible with the canvas renderer, however it will should be fairly easy to accomplish with the webgl renderer https://github.com/xtermjs/xterm.js/pull/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?

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.

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.

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

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.

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.