Hacker News Reader

Comment by aragonite | Hacker News Reader

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.

View on HN

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

BTW, the DEC VT320 did this too, some 30+ years ago: https://www.youtube.com/watch?v=tSJfzrSA0ec

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.

Scrolling feels completely different with smooth scrolling setting on and off, when you use mouse wheel to scroll. I always keep it off.

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

> 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!

I just did a quick experiment, that's all.

I'm on the VS Code team and maintain xterm.js.

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

Reply on news.ycombinator.com