Terminal Smooth Scrolling
flak.tedunangst.com
flak.tedunangst.com
Anyway, what I don't remember is: Could typical hardware terminals do this with a scroll region, or only with the whole screen? For a full-screen scroll, I suppose one could quite easily move everything by gradually offsetting the vertical sync a bit, but for a block of lines there would have to be something more complicated, like offsetting the input to the character generators for some scan lines. Is that what they did?
NES (a 6502, if it matters) had a different approach, where you had four sections with their own memory regions for tiles and sprites. You'd then tell the NES how to lay them out, e.g. if they were next to each other, how they'd wrap, if one was duplicated to another slot, etc and then the scrolling was handled by hardware. This is how Super Mario implemented the long sprawling levels (and I believe why the first wouldn't let you go back).
As for e.g. VGA buffers on x86 for example, as far as I know there's no (standard) way to have them shift. I could be wrong. However I've had to write a few vertical scroller rasterizers before for VGA buffers and I've always done them manually, usually with some cleverness to avoid actually writing to the buffer when it wasn't necessary (since that hit a memory mapped region and thus was much slower than RAM).
Edit to add; looks like you can do line based scrolling in text mode with the Preset Row Scan register [4].
Edit to add again; I think there's similar stuff in Vesa Bios Extensions (i set a SetDisplayStart, but I'm not sure I see a equivalent to the offset register), but if you're using a UEFI GOP framebuffer, I don't think there's anything similar, and you have to manage scrolling yourself. :(
[1] http://www.osdever.net/FreeVGA/vga/crtcreg.htm#0C
[2] http://www.osdever.net/FreeVGA/vga/crtcreg.htm#13
[3] http://www.os2museum.com/wp/dosv-graphics-text-modes-and-scr...
The line was there, and you’re just waiting for it to materialize. This was a far different experience from watching the cursor crawl across the screen. There you didn’t know what was coming next. With the smooth scrolling, you did and were just, stuck, waiting on it.
Personal taste, to each their own, but I hated it.
It looks better if you have a 300 bps connection where you don't get angry by the delay it introduces. For a modern terminal, I'd suggest that the full backlog should be rendered in .5 seconds for it to still feel responsive.
And yes - I know it's a complete waste of compute resources, but, then, I also like Cool Retro Term, and it uses more compute power than NASA used to send people to the Moon, and does that 60 times per second.
I'm a cinema person, so, for me, 24 fps is the right framerate for everything.
I have found that I like TVs using interpolation to achieve a higher FPS: it makes old movies feel more alive.
Some people have reported they don't like the high framerate, as it make them feel they are watching a TV series.
Could you recommend a modern terminal that would have the features you suggest?
I'd be curious to try them to see how different it feels!
No. There's nobody doing it. I suggested it to the VTE team (VTE is the base of a lot of terminal programs running on Linux), but they (rather sensibly) highlighted the complexity this would add to the codebase and the numerous corner cases we should be worried about.
When configured properly it is, IMHO, more readable than any other terminal out there. I feel that just a little bit of "noise" helps make the text easier to read.
It's a feature you can configure
> Personal taste, to each their own, but I hated it.
I have trouble understanding how someone can hate an optional feature. What you might hate is the default configuration.
I've heard people complain about desktop switching effects on hyprland, saying they are too slow. I've found they're helpful visual hints, but we all have different preferences for "speed"
By making the desktop switching effect happen within a smaller time budget, they are not intrusive at all. It's less "buttery smooth" but it feels better than the lack of animation, or the slowness of perfect buttery smooth: it's as if the visual system of the brain could use this extra information to better interpolate and keep a visual map.
If you want smooth scrolling in the terminal, yet want to scroll text very fast (like when looking for patterns inside binaries), maybe drawing the pixel lines by packets of 5 will achieve the speed you feel comfortable with, while still providing hints to your visual system.
That's weird.
You have trouble understanding how someone could hate an optional feature and -because of that hate- turn that optional feature off and keep it off forever?
No, I have trouble understanding why someone might hate an optional feature that's either turned off by default, or that they can turn off with little effort then keep it off forever.
The lack of the feature in the first place is more of a problem. With empathy towards people who might like the feature, you see the presence of the feature as a good thing, even if it's no use (or even an inconvenience) to you. If it's an inconvenience, what you hate is the default setting.
Example: screen readers. I've been sometimes surprised by having Windows start reading text aloud after pressing a shortcut, but I then thought "actually, that's nice because people who can't use a screen have this great feature working out of the box"
OP even acknowledged that other people may like this feature: "Personal taste, to each their own, but I hated it."
Seemed like a perfectly reasonable expression of opinion to me.
One can hate something while simultaneously acknowledging the reasonableness of its continued existence.
It's distressing that (G?)PP either doesn't understand this, or is unwilling to spend enough time on reading what OP wrote to notice that this is the sentiment that OP is expressing about smooth scrolling on the VT-100.
I already know there are many things that I don't understand, but I'm willing to spend large amounts of time to improve my understanding
> I have trouble understanding how someone
is generally felt (if not understood) as aggressive, as in passive-aggressive. You literally say you "have trouble understanding *foo*" as if the problem was on your side but what is understood (and more often than not meant) is "how could anyone/you be so stupid to do/think/try this is beyond me".
"I have trouble understanding why you would use lib *foo* instead of lib *bar*" is very common on stackoverflow and other comp. sci. forums. Maybe people think it's a polite way to say things but it's worse because it's poison under veneer. If you want to point out you think it's stupid just say "I think it's stupid". 1/ it's stupid is better than you is stupid 2/ it's closer to what you want to express (or are people really so self-centred that someone else doing something they think is stupid breaks their brain ("trouble understanding")).
my 2ç.
I didn't think it was stupid, I had genuine trouble understanding how could an extra feature be hated - it didn't make sense: I thought it was maybe not the feature itself, but either the default setting, or the fact that it was a setting that could be tweaked.
But when something doesn't make sense to me, I've found it often means I've overlooked or missed something that may be evident to others (sometimes I even write: "what have I overlooked?")
Here, I missed that it would be interpreted to mean "poison under veneer".
I'd like to improve, as in "not being perceived as aggressive", so I appreciate your feedback!
Is this your own coinage? It's very good and I'm totally stealing it either way.
> Is this your own coinage? It's very good and I'm totally stealing it either way.
Yes, English is not my first language and I was trying to remember a colloquialism to translate. I was thinking of the words "veneer" (often used to indicate something is hidden with malice in my mother tongue) and "poison" as in "a viper's tongue" which is "a sharp tongue" in English and other words but I couldn't remember any aphorisms in either of languages. I thought both words would be evocative enough to convey the meaning so I went with it.
Characters would be received pretty fast, so your reading wasn't lagging by much.
I wanted to make it look like a "real computer".
This is now really what most gui apps do when you press page up/down in fact.
The one thing I did use it for was to collapse a complex display with lots of line drawing characters - customers were super-impressed by the smooth roll-up of the display as it changed from a complex input setup to a processing phase (done by defining a scroll region across a few text lines and simply outputting a new line feeds).
I realize that hardware-smooth-scrolling is different, and you emphasized that you weren't limited by the mainframe speed per-se, but I can't help but think these two 'smooth scrolling's are similar in name only. I can't picture how you could have the same problem with the smooths-scrolling feature described in this post.
Simply, I would not want anything hindering the dumping of information to my screen. I am no longer rate limited by baud rate, racing to hit ^S and ^Q to pause and continue the display output.
Rather, I'll hit a command, let it dump however many lines it wants, and then scrollback in the buffer with the scroll bar to see what I missed. This also effectively pauses fast moving output as the buffer continues to fill while I'm scrolled back.
If the information is still flowing so fast I can't make sense of it in my text window, I can either search on the text live, or Select-All, Copy a large swatch of it, switch to another window and paste it into an editor buffer and have my way with it.
My terminal buffer has "infinite" scrollback. Yes, there have been times when I've left processes running over the weekend to come back and having my machine cratered with swap because my terminal buffer was far, far too large, gorged with logging messages. C'est la vie, I'll take that minor inconvenience over the flexibility of an infinite scroll buffer.
The modern terminal environment for me is quite different from the old VT-100 days. Perhaps if the smooth scrolling was faster I would not have minded it as much back then, but it wasn't and I found the default VT-100 rate too slow. Data can scroll by too fast, but there was always other mechanics to pause and such that I can use as much or as little as I wanted, rate limited by me rather than limited by the terminal. I found that way much more flexible and suited to how I consumed information.
I think I agree with you that smooth output from command line output isn't necessary, and a fringe benefit at best.
This is the Falco 5220e terminal emulated by MAME. It's running the vttest tool.
A programmatic "infinite parallax wallpaper" made of a few shaped blobs (to avoid making the foregound text hard to read) could help our visual system (build for a 3d world) keep track of the scrolling text without doing smooth scrolling directly, and without the helping "visual hints" scrollbars provide.
I'd be interested to hear comments from someone who likes this and if it's difficult to read and they don't care or make other modifications to increase contrast etc
Maybe this is a problem of the background image you've selected? Or maybe you don't like it 100% of the time?
I like calming background images, especially when they are animated, and turned on and off at whill.
I have a hotkey to toggle a nature scene: I've found that it helps me concentrate when I'm thinking about a coding problem: demo in https://www.reddit.com/r/unixporn/comments/11w3zzj/hyprland_...
The bottom part of the image has subtle movements (the wind effect on the grass)
The shortcut key idea is interesting.
I have nice syntax highlighting /colors / statusbar / desktop wallpaper etc but if I'm trying to write / read terminal / code, contrast is king.
What I'm kind of grokking from your comment is the text on image just doesn't really bother you
It's a wonderful sub to find inspiration and great ideas!
> What I'm kind of grokking from your comment is the text on image just doesn't really bother you
It sometimes bothers me, so the default is to have it off.
But I found it can help me concentrate so I have a shortcut.
I don't know if it works by reducing the contrast of the code or by distracting my mind, but it helps me think more about the code.
And in a terminal I'm usually scrolling with pgup/pgdown or using search in a pager.
Scrolling line-by-line at a fixed speed like in the video is very rare.
On Edge I do the same with `edge://flags/#smooth-scrolling`, but I've found there're 2 separate usecases, one where smooth scrolling helps, and one where it doesn't, and a separate usecase where the scrollbar stands in the way:
- when scrolling with page up/page down, whether on Edge or on a terminal scrollbuffer, the tactile feedback of which key is pressed, and how often, is enough to keep track of the position. the scrollbar provide extra hints
- when scrolling with the mouse, the smooth scrolling provides all the information I need. the scrollbar only helps me know if I'm close to the bottom of the page
- when not scrolling but reading, the scrollbar is redundant and distracting. I like the new UI hiding the scrollbar, because I can better concentrate on the text.
Another flag I love in edge is `edge://flags#enable-force-dark` with `selective image inversion based on transparency and number of colors`: it gives perfect dark mode on every website, with no plugin needed!
Took way too long to find the link!
For example, in VSCode, I've toggled the "editor.smoothScrolling" setting from true to false and back without perceiving any noticeable difference. This is also true for several other applications where I've tried the same thing.
I understand the concept of 'smooth scrolling' as it was traditionally defined in opposition to "scrolling by lines" (like when using ctrl+up/down in VSCode), where the movement occurs in discrete increments. In modern apps where scrolling generally seems continuous regardless, the distinction is unclear to me.
Default scrolling is line-by-line, i.e. the whole screen moves up by 16 pixels (or whatever height your font is) and the new line gets printed on the bottom.
Smooth scrolling is when the screen moves up pixel by pixel
It might not be noticeable in a text editor, but it sure looks impressive in a terminal since you can actually read while it scrolls. On whether that's useful or not will probably depend on the actual use-case (and user), but it sure looks impressive
BTW, the DEC VT320 did this too, some 30+ years ago: https://www.youtube.com/watch?v=tSJfzrSA0ec
What I'm confused about is what exactly am I toggling when say I toggle the 'Use smooth scrolling' setting in Firefox, or the 'editor.smoothScrolling' setting in VSCode. I just never was able detect any difference.
Maybe it's as you said, the effect is just very subtle.
Or it scrolls more like in a browser or image editor, where is can also scroll by fractional lines (pixels essentially), which, of course, after the scroll looks the same but during scrolling it looks more "smooth"
At least in VSCode and probably some other software (especially if it's electron based) scrolling using touchpad gesture or other device that provides "smooth scrolling" (for example a thinkpad trackpoint) is always smooth similar to how when you drag the scrollbar with mouse.
VSCode "editor.smoothScrolling" has an effect when you scroll using scrollwheel. Typically turning the mousewheel by single indentation scrolls by some fixed amount of lines ~3-5 depending on configuration. When "editor.smoothScrolling" is off this scrolling by instantly moving everything up. When "editor.smoothScrolling" is on as the description of this setting explains it plays an animation which moving the in as small increments as screen resolution and screen refereshrate allows. It's only a fraction of second, but since most screens now are are at least 60hz that's still 6-20 frames.
Different aspect of smooth scrolling (which is what similar named setting in other software might affect) is how the scrolwheel events are handled and reported. Typical mouse wheels rotate have physical detents making them spin with 15° steps, or 24 steps per revolution. And for a long time corresponding wheel events happened at roughly similar rate/resolution. Even if some the libraries were written with future proofing in mind that doesn't prevent applications and wrapper libraries making bad assumption about these values. For example windows API used to report values in increments of 120. That in theory supports wheel events with resolution down to 15/120=0.125°. But since for a long time the numbers it reported were always multiple of 120, a bunch of software did something like this `int scrollAmount = wheel_change / 120`. Thus throwing away information about scrolling at steps smaller than 120.
So a smooth scrolling can also refer whether everything in the software stack between software/input library/os API/driver correctly handles high resolution scrollwheel events.
What I didn't realize until now is that 'smooth scrolling' in VSCode etc is an added animation to turn what was originally a discrete, instantaneous change into an gradual animated transition. Smooth scroll in this sense is (I suppose) more about enhancing visual appeal or aiding accessibility for users who have difficulty tracking abrupt changes on screen than about allowing more precise control over scroll positions.
For Firefox, smooth scrolling behaves exactly as I expect, but it affects scrolling via the cursor keys only (and the space bar), not via the mouse/trackpad. Also, the animation is quite fast, so it's easy to miss. (In Firefox, scrolling via the trackpad is always smooth; I haven't used a mouse with a whell in ages, so I don't know how that behaves.)
Smooth scrolling in VS Code is primarily about animating scroll events such that scrolling with a mouse wheel doesn't just scroll an increment immediately but over a fixed time, updating at a high refresh rate. This is supported in both the editor and the terminal.
The other part of smooth scroll is being able to render lines offset on the y-axis which is supported by Monaco (the editor part), but not xterm.js (the terminal part). I can't actually seem to find the issue for this, but I've been wanting to implement it for a while. It's quite simple to offset the text, the slightly harder part is to render an additional row so you can see a partially rendered line on the top/bottom.
Should I submit a feature request to add smoothness to the scrolling that happens when the cursor moves off-screen (e.g. by using the cursor-down key)?
> For Firefox, smooth scrolling behaves exactly as I expect, but it affects scrolling via the cursor keys only (and the space bar)
You just cleared up two mysteries that have been puzzling me for ages!
(Same in iTerm2. In Linux, Terminator can scroll to partial lines, but output is instant, so it doesn't have the effect the OP is looking for.)
I wish it worked with man pages, vim and less. But that sounds like a hard problem.
For example, I don't follow the messages. I read them. Or, really, parts of them.
Raw, un-smooth scrolling, and a high-refresh rate display means I can fix my eyes in one spot and consume the matrix
Similarly, if you have a text editor that divides the screen into two horizontally-tiled buffers, you can define the scroll region (top margin/bottom margin) appropriately and have the same semantics.
But if you have vertically-tiled buffers (open Emacs, C-x 3) then the top margin/bottom margin model no longer works. If you "scroll" one of those buffers, you are doing it to both of them, and you need to overpaint the other one afterwards; on a fast enough connection that's invisible within standard terminal semantics but will have odd visual artifacts for a smooth scroll.
Like most other things in the comments here, this is addressed in the article.
Certainly for VT100 they do not - you can define the scroll region, but it's strictly "between line x and y" or "the whole screen" and you can only scroll up/down the entire region.
The article only address smooth scrolling of entire lines. How do you "scroll only the buffer on the right side of the screen"?
VS.Code's supports smooth scrolling in both the editor and terminal window, but it's off by default. There's settings for it.
If you're not using the controller registers to scroll, and you're just blasting scrolled text into the video memory... yeah, you can't get smooth scrolling with that. But you're also missing out on hardware accelerated scrolling, so :P
(Like reprogramming the CRT controller on the fly to have reduced height lines at the top and bottom of the screen while doing the smooth scroll).
that said, I like smooth scrolling lots better than the original IBM PC CGA adapter that had blink scrolling.
I think they just turned of video, otherwise they would have gotten snow.
Not novel, but fun way to get more resolution than you have but for narrow use cases.
I'm on relatively modest hardware and just scrolled my hardest using a trackpad in urxvt, xterm, xfce4-terminal, gnome-terminal, and they're all practically instant. You'd need to _introduce_ lag to have any pixel-by-pixel smoothing even be noticable.
I consider pixel-by-pixel scrolling unnecessary eye-candy not worth the tradeoff. Consider that the capabilities in both hardware and software to do smooth/pixel-by-pixel scrolling in terminals have been around for decades - the reason it's not more common isn't necessarily technical.
You may have a different preference but that doesn't make the status quo sucky, laggy, or sad.
Trackpad scrolling works fine for me, in everything I can think of. (macOS+Terminal.app => seems fine. macOS+iTerm2 => seems fine. Linux+Terminator => seems fine.)
(Terminator will even scroll to partial lines with the trackpad. It won't do the sort of scrolling described in the OP, though … but that's not "sucky laggy scroll", either.)
I wouldn't like smooth scrolling when I use PageUp/PageDown, unless it added minimal latency, because for full pages it would break the illusion.
However, it may feel natural and normal with small and precise movements like multiple finger trackpad scroll for a few lines - at least if there's an acceleration curve to reduce the fps for large movements (many lines, or quick movements to scroll by full pages): it would help keep the perception of a low latency between the action and its "immediate" execution.
I’ve used Macs for a number of years - and on macOS, mouse scroll events have been very “precise” for a long time - sending scroll events in fractions of a line. Scroll isn’t a button. It’s an axis. It feels great - because you have direct, continuous control.
I moved to Linux mint a couple years ago and tried to bring my Apple magic touchpad with me. (I prefer it over a mouse while coding.) Linux has APIs which return precise scroll offsets, but a lot of apps don’t use them. Instead, Firefox will wait until I’ve scrolled an entire line worth, then emulate a smooth scrolling event to “catch up” to the scrolling I’ve already done. It feels horrible. Mushy and laggy are the right words. IntelliJ has the same problem - I assume precise scroll events don’t survive whatever event library they’re using. I’ve given up and gone back to a mouse on Linux. And turned smooth scrolling off.
Smooth scrolling is a great idea - but for my money it’s only worth it if you have direct, continuous control over the scrolling position. And unfortunately on Linux (and probably windows) that’s held back by bad software support.
1) Most mouse scroll wheels feels discrete / have low resolution, so they behave more like discrete press. With my current mouse, each wheel up/down event does scrolling of several (~5) lines.
2) There is scrolling from keyboard (up / down / page-up / page-down), which are definitely discrete events, so any smooth scrolling from that is laggy.
But turning off smooth scrolling made scrolling with those other devices feel better (to me), as I recall.
There's also the pointless visual distractions (e.g. firefox blue flash) even after killing web page animations,
/* No blue swipe on tabs when loaded */
.tabbrowser-tab .tab-loading-burst {
display: none !important;
}
This is my userChrome.css (I also have a megabar remover in there, that's not shown here):
* {
transition-delay: 0ms !important;
/* This is the magic to kill it 100% */
transition-timing-function: steps(1, jump-start) !important;
/* Animation Killer */
animation-delay: 0ms !important;
animation-duration: 0ms !important;
animation-iteration-count: 1 !important;
animation-timing-function: steps(1, jump-start) !important;Also I have ui.PrefersReducedMotion=1 set in about:config.
For those unaware, Ted is a core developer of OpenBSD.
An interesting interview with him can be read here:
https://www.undeadly.org/features/2015/10/beastie_pl_intervi...