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
Feature Request: Smoothly scroll in new lines #1400
Comments
This seems like it'll be a dupe of #1066. When that one's fixed, this should be too. Thanks! |
I may have been premature in closing this. This is definitely not a dupe of #1066, this is something entirely else. I'm not sure how possible this is. I guess hypothetically we could render a portion of a line at a time, or just render the frame and then apply some sort of transform on it. Getting the velocity by which to scroll these lines might be hard though - how fast should a new line appear on the screen? What happens if multiple lines are output during the course of a frame? I'm not saying it's impossible, but it will be hard. |
If there were an internal buffer, when there is a pause in output, all the lines could then render in. But this should be an option to enable, rather than a new default. I would say the same for "typing" of lines, instead of an instant "pop-in" |
FYI: iTerm2 counterpart |
Note that in addition to the VT100 I don't think the exact speeds matter that much, since the smooth scrolling on a VT100 was originally 6 lines per second (STD 070 gives that value too), while on later terminals the default speed was 9 lines per second. I believe the original value was simply the result of the monitor refresh rate (60Hz) and the number of scan lines in a row (10). |
I think this issue actually includes three related but different things:
|
From #8548 |
Obligatory reference to Pavel Fatin's Scrolling with Pleasure. Scroll smoothing compensates for low precision using animation. #8548 was about alleviating low precision by utilizing high precision input. Same problem, two different solutions. With the summary as it stands, this issue addresses animation specifically: there is no overlap with #8548. A good way to tie them together is with a UX tasklist-style issue. |
https://gyazo.com/75806dcc6eceeb640c733769556b1d2a The best implementation of scrolling in any text editing program, let alone just the terminal plugin. |
Hi, was there any update on the issue? |
Notes from around the web: That PR implements it as a timer that continually scrolls a single line at a time even when the accumulated scroll delta is bigger than that, so the scrolling doesn't happen all at once. I was more picturing this as a viewport that accepted a floating-point offset, so that we could have a fractional amount of lines at a time. Like, for precision trackpads where you might not always have 100% of a row scrolled. |
@zadjii-msft As I understand it, the xtermjs issues you linked are regarding mouse-wheel scrolling of the scrollback buffer. This feature request was for smooth scrolling of the terminal output. The simplest case being when you output a line feed at the bottom of the screen, it should smoothly scroll the new line into view. The complication is that you generally need to be able to render more lines than you actually have in the buffer. For example, if you have a 30 line screen, and you're going to scroll up a line, you'd typically just erase the top line, move everything up by one, and then insert your new content on the bottom line. With smooth scrolling, though, the top line is sliding out of view at the same time as the new bottom line is sliding into view, so you actually need to be rendering 31 lines at the same time. This is probably not a big deal if you're doing a full screen scroll and you have a scrollback buffer. But it ideally needs to work with margin-based scrolling too, and that becomes trickier. If it's not practical, though, we could probably get away with just letting the top line disappear in those cases. It should still a produce a reasonably nice effect I think. |
That's an excellent point! I think letting partially visible lines simply disappear would look a bit weird. Another pragmatic solution would be to just disable smooth scrolling when margins are set. With |
Funnily enough, the only times I've actually seen smooth scrolling deliberately enabled have been with margins also set. The one case was in vttest, which naturally enough has a test of smooth scrolling within margins. The other case was with a set of ASCII Christmas animations, some of which relied on smooth scrolling for effect. Not that these are critical use cases, but if we are going to the effort of implementing smooth scrolling, it would be nice if it could handle as many of these situations as possible. And I've just been looking through my terminal collection to see how others are implementing this, and the one example I found was Reflection Desktop, which looks to me like it's letting the top line smoothly scroll out of view, before rendering the new line at the bottom. That seems to work reasonably well. I also wondered if we could do something similar to the way the original hardware probably worked, where we rely on the fact that the area being scrolled is already in the memory bitmap, so you can scroll most of the bitmap content directly, and just render the new line coming into view. In that case you don't care that the top line is already gone from the buffer. I think we already do something like this for full screen scrolling in the GDI renderer - it would just need to be extended to support arbitrary margin regions. I'm not sure if that approach would be applicable to the DX and Atlas renderers though. Anyway, none of this is essential for me - I'm just brainstorming ideas. |
One thing any smooth scrolling feature needs to account for is the rendering backlog. Physical terminals signalled the computer via the RS-232 signals to stop sending characters when its buffer was full. Windowed terminals don't (or can't) do that. A usability improvement over the behavior of these older machines would be increasing the speed proportionally to the backlog - so that it never takes more than "x" seconds to reach the end of the buffer. The approach Reflection uses is the same a couple physical terminals I have used rely on - the last line only scrolls into the screen if there is a rendering backlog and other lines to be rendered after it. If there is no backlog, the line shows on the screen (because, usually, it means the user is typing and they'd like to see what is being written. |
adding notes: S44JaCh.-.Imgur.mp4which I got from https://news.ycombinator.com/item?id=38851642, which is about https://flak.tedunangst.com/post/terminal-smooth-scrolling |
@zadjii-msft Lmao, I read the same article on Hacker News and came here to say the exact same thing. |
Yes, please find inspiration in the recent posting by Ted Unangst (OpenBSD). |
Summary of the new feature/enhancement
Some hardware terminals allowed smoothly scrolling in new lines. It should be possible to implement this kind of feature in a software terminal emulator as well.
YouTube demonstration (VT525 smooth scrolling):
https://www.youtube.com/watch?v=Iju_pOQM0a0
The text was updated successfully, but these errors were encountered: