I remember actual hardware terminals doing this. I also remember keeping it turned off, partially because it was slow (as many others have already said), but also because I felt weird when scrolling one line at a time. As I remember it, there was no ease-in or ease-out to the motion, but instant transitions from standing still to rolling speed to standing still again. Jerky.
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?
Not sure historically but at least doing some OLED programming these days it's often the case they support changing where the pointer starts (in terms of rows or columns) and allowing the behavior of wrapping the cursor around, meaning that when you'd do a full scroll the rows simply wrap around. If you don't overwrite anything in the video memory, then you just see the content from the top/bottom show up at the bottom/top, but if you did (e.g. to implement efficient whole-screen scrolling) you just had to re-paint the lines that were offset, instead of the whole screen.
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).
You can set the Start Address to shift the display [1], I haven't used this in graphics mode, but in text mode, if you set the line offset to 128, in 80x25 mode, you get easy scrolling (still line based though) with wrap around or you can use the offset register to start at 0 at a given scanline [2]. I think I picked up this technique from this article [3]
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. :(
We had smooth scrolling on the VT-100. I hated it. I found it far too slow, even on low baud rates.
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.
With modern terminals, we can do much better - accelerate when there's backlog and even add motion blur if we feel like. It's not like someone will be able to read a wall of text scrolling past the terminal window faster than the screen refresh rate.
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.
Depends on the time you want the virtual shutter to be open. I agree with you it can get excessive if it gets too pronounced, but a long blur is also a visual indication a character jumped more than one line during the (virtual) screen refresh (virtual, because we want it to look consistent, regardless of refresh rate). It should also disappear before the characters settle into their grid.
I'm a cinema person, so, for me, 24 fps is the right framerate for everything.
> Could you recommend a modern terminal that would have the features you suggest?
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.
If Cool Retro Term had tab support on MacOS it'd be my daily driver.
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.
Smooth scrolling on the VT100 was 6 lines per second, but on later terminals you could adjust the speed to a certain degree, as much as 18 lines per second on the level 5 terminals. It's possible you'd still hate it even at that speed, but I wouldn't right it off completely just because you disliked the VT100 implementation.
> We had smooth scrolling on the VT-100. I hated it. I found it far too slow, even on low baud rates.
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.
> I have trouble understanding how someone can hate an optional feature.
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?
> 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"
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.
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")).
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.
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.
Personally speaking, bad defaults are never fixed forever. They're fixed once per machine, or once per account, or once per install, or in some cases, once per update. The first encounter is annoying (especially so if it takes a while to discover that the annoyance can be turned off). Later encounters build on the original annoyance, which grows to hatred. Especially for folks working in IT dating back to that era, setting up countless machines, that's a lot of exposure to bad defaults.
For awhile as a kid, I had smooth-scrolling on a terminal (probably a Wyse WY-50) on dialup 2400 baud, and I recall that being just about right for reading many lines of text as they scrolled on a non-cursor-addressing BBS.
Characters would be received pretty fast, so your reading wasn't lagging by much.
Back in the early days when I was working on a PET 2001, I wrote a routine to slow down the printing of text, so that it would look like it was coming from something akin to a 300 baud system.
Yeah it should be so fast you can't actually read it, but slowv though so your eyes van track the line of text where your left off reading and know where to continue instinctively. Like a subtle cue.
This is now really what most gui apps do when you press page up/down in fact.
I was never a fan either (some VT100 compatibles did it better than others, always too slow for my taste though).
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).
At University over three years with perhaps 50 vt220 terminals hooked up to the cluster, I don't remember anyone using it other than when looking through the menu options. I think for the exact reasons you give. Reverse video mode was equally unpopular.
would you be willing to try it on a modern terminal? unless I'm misunderstanding, you tried it on a VT-100 hardware terminal, which almost certainly means you were on a mainframe from 30+ years ago. If I'm wrong , please let me know.
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.
To be fair, I have not tried a modern version. But the way that I use a modern terminal, I probably would not care for smooth scrolling.
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.
Fair enough, thanks for the elaborate reply. do you edit text in the terminal? My main reason for wanting this feature is to be able to scroll up/down in vim; having the text jump a line at a time makes it slightly harder to read, which ads up over time.
I think I agree with you that smooth output from command line output isn't necessary, and a fringe benefit at best.
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 have never been able to do transparency or background images in a terminal- it's so distracting to me.
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
I also have a TamperMonkey script installed to prevent web sites from hooking the arrow keys to do smooth scrolling (or worse: navigate to another page).
I'm sure there must be several out there but the one I use is: <https://github.com/isaacl/keycodeScript> with PgUp/PgDn/Home/End (33, 34, 35, 36) added.
> Hmm, not sure. The first thing I do in Firefox is disable smooth scroll.
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!
What exactly is the modern definition of "smooth scrolling"? How is it supposed to differ from non-smooth scrolling?
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.
I think the video on the linked page sums it up pretty nicely:
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
Thanks for the explanation and the link. This is exactly how I've always understood 'smooth scrolling' to mean.
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.
usually it changes how the scroll wheel behaves. it either scrolls in steps of n lines (n=1 or n=3 for example), bringing n "new" lines into view with every step.
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"
Could it be that you are using touchpad to scroll? Or maybe you are on macOS?
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.
Yes, you're exactly right: I haven't used a mouse wheel or the PgUp/PgDn keys to scroll in years, which explains why I haven't noticed any difference from changing the setting (as another commenter also pointed out).
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.
Very interesting. I expected smooth scroll in VSCode to do like the video does. But no, it does not affect single-line scrolling. It affects scrolling a page!
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.
> 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.
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)?
> Very interesting. I expected smooth scroll in VSCode to do like the video does. But no, it does not affect single-line scrolling. It affects scrolling a page!
> 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!
This is default on Mac if you use the Trackpad. Just to be sure I just tested with "man ls", which is also used in the example video.
If I use my keyboard, I prefer to not have smooth scrolling.
Scrolling with the trackpad is continuous and smooth in Terminal.app. On macOS I often prefer to cat files and then scroll them myself because of how nice it feels - and how much direct control I feel like I have over the scrolling position.
I wish it worked with man pages, vim and less. But that sounds like a hard problem.
Yeah I’m not sure about it being “incompatible.” It’s really just a framerate thing. In both cases we move a whole line in x millseconds. And either we’re rendering in-between frames or not. People have different needs and and wants when it comes to framrate.
It also introduces delays. And if you're doing anything more complex than holding down the scroll button, the illusion of "either we’re rendering in-between frames or not" can disappear, because of frames on either side of the move that prove the speed is not consistent between smooth and non-smooth.
I absolutely love smooth scrolling in the VTE terminals on Linux, but I can't find anything other than maybe the default terminal app (which I don't like) and iterm2 (which I don't like) that does it on Mac. As the author said, just about every terminal has a GH issue open asking for it with nothing but 'this would require rewriting a lot'
One of the basic problems here is the semantics of "scroll". If you have a full screen of text and then "add a line at the bottom" then you're going to scroll everything up by one line. That's pretty clear.
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.
>The TTY sequences to insert or move lines give all the information needed to avoid scrolling other parts of the screen.
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"?
On later DEC terminals you could also set left and right margins (lookup DECSLRM). They didn't support smooth scrolling when those margins were enabled, but I don't see why a modern terminal emulator couldn't handle that.
Windows Terminal is pretty good and a new terminal emulator written in the last few years. No smooth scrolling, here's the GitHub issue requesting it: https://github.com/microsoft/terminal/issues/1400
VS.Code's supports smooth scrolling in both the editor and terminal window, but it's off by default. There's settings for it.
Actual terminals used to do this, like the DEC ones. The Tandy 2000 (non-IBM compatible DOS PC) could imitate this behavior as well, enabled with a keyboard toggle.
That's not at all my recollection! Have you got an example? As far as I know, VGA text modes were character-ROM based with a 16 bits per text buffer cell (8 bits each character/attribute) and so there's literally no way for this to work.
You could program the scroll registers to achieve pixel-level scrolling for the entire screen or, if you got even more clever, part of the screen. But there was no toggle to enable this behavior for all scrolling in text mode.
If you're using the CRT controller register to scroll, you can do smooth scrolling if you want. It's not a cunning stunt, it's just part of the interface you're using (or maybe it's not, there's a lot of references to various VGA devices not having the same behavior; I don't have lived experience trying to get these things to work, and most applications I used in VGA modes were likely to be conservative and use the part of the spec that worked).
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
You don't need tricks to do it with VGA. There is a register specifically for that purpose. You can do it with CGA as well but that does require tricks.
(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).
Wow, so much discomfort expressed here about slow scrolling. Are we all adopted to read tons of pages of terminal output flying by? I'm certainly not, and XOFF doesnt work anymore in many setups. Pagers for the rescue, though not working everywhere...
I remember writing my own smooth scrolling file viewer on DOS. You could use the character registers for the display controller (think it was VGA, 80x25 mode).
Not novel, but fun way to get more resolution than you have but for narrow use cases.
Not novel but it was esoteric. I remember a friend showing off his own custom communications software with smooth scrolling at work and we were all blown away with how cool it was.
I don't understand the downvotes. Most terminal emulators have sucky laggy scroll (that becomes super visible with the type of scrolling you do with a trackpad) and I'm not aware of any that do pixel-level smooth scrolling. Which is sad, smooth scroll works really well with such 1:1 input devices.
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 think it's an issue of separating keyboard/trackpad/mouse scrolling: it may be beneficial in some cases, it may be burdensome in others.
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 absolutely hate smooth-scrolling. It's one of the first things that I disable. I can't stand the way smooth-scrolling "feels,"... "mushy," and "laggy" are the best words I can think of to describe it.
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.
Maybe it's just what you're used to - having got a Mac for the "premium experience", I found it sluggish and slow (albeit compared to a stripped down X11 system, rather than a full-on compositor experience)
I pretty much agree with OP, but i could see an argument for smooth scrolling with precise mouse scroll events. But:
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.
I seem to recall smooth scrolling on the Mac having the same basic issue as elsewhere. It takes an instantaneous scroll input and turns it into an animation. Scrolling half lines is fine and all, but I want the scroll position to jump to where it's going; possibly with multiple jumps if my input is over several frames.
Yeah that makes sense to me. Keyboards and scroll wheels don’t have the precise control that trackpads (and Apple’s Magic Mouse) have. Clicky scroll wheels aren’t magically better on macOS. It’s the continuous, precise scrolling experience of a good trackpad that fixes it. Apple nailed it if you use their hardware and software.
I personally hate anything that adds unnecessary latency, that's why I disable smooth scrolling and desktop effects. I even have a CSS hack to disable all transitions, animations and fades on the Web. It makes everything instantaneous, which I really like. I also use plain X11 without a compositor, so I have a super low latency desktop that feels really fast.
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?