[HN Gopher] Terminal Smooth Scrolling
___________________________________________________________________
Terminal Smooth Scrolling
Author : ingve
Score : 141 points
Date : 2024-01-03 07:32 UTC (1 days ago)
(HTM) web link (flak.tedunangst.com)
(TXT) w3m dump (flak.tedunangst.com)
| okasaki wrote:
| Hmm, not sure. The first thing I do in Firefox is disable smooth
| scroll.
|
| 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.
| Findecanor wrote:
| 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.
| hexo wrote:
| Thank you very much!! I too find any kind of smooth scrolling
| very off putting, and was looking for this fix for a long
| time.
| csdvrx wrote:
| > 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!
| perryizgr8 wrote:
| I want to try it but I'm not sure how to? The author gives a
| control sequence to enable it, but I don't see a download page or
| git repo.
| neuromanser wrote:
| Probably https://flak.tedunangst.com/post/vertigo
| ciex wrote:
| The article mentions `.vimrc`, which matches the format of the
| lines starting with `set ...` but that does not result in
| smooth scrolling for me.
| hackernudes wrote:
| https://humungus.tedunangst.com/r/vertigo
|
| Took way too long to find the link!
| stevebmark wrote:
| Does enabling smooth scrolling require downloading the
| author's custom shell? If so, this article should be flagged
| as misleading.
| whartung wrote:
| 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.
| csdvrx wrote:
| > 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.
| simoncion wrote:
| > 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?
| csdvrx wrote:
| > 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"
| sevg wrote:
| OP didn't say "I hate this feature and this feature must
| be killed."
|
| 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.
| csdvrx wrote:
| I understood that as hating the presence of the feature,
| so I got it wrong
| simoncion wrote:
| Yep.
|
| 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.
| csdvrx wrote:
| > It's distressing that (G?)PP either doesn't understand
| this, or is unwilling to spend enough time on reading
|
| 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
| johnchristopher wrote:
| Well, here's one:
|
| > 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 2c.
| csdvrx wrote:
| Very interesting, thank you!
|
| 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!
| dcminter wrote:
| > poison under veneer
|
| Is this your own coinage? It's _very_ good and I 'm
| totally stealing it either way.
| johnchristopher wrote:
| > > poison under veneer
|
| > 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.
| dcminter wrote:
| Honestly it's brilliant.
| zh3 wrote:
| 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).
| rbanffy wrote:
| 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.
| aqfamnzc wrote:
| I agree with you on acceleration. But motion blur in a
| terminal sounds like something straight from hell.
| rbanffy wrote:
| 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.
| csdvrx wrote:
| > 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!
| com2kid wrote:
| 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.
| wkat4242 wrote:
| 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.
| neilv wrote:
| 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.
| whartung wrote:
| 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.
|
| I wanted to make it look like a "real computer".
| Mountain_Skies wrote:
| Now you can ask ChatGPT questions and get a similar effect.
| dcminter wrote:
| 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.
| j4_james wrote:
| 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.
| gosub100 wrote:
| 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.
| startaq wrote:
| Here's how smooth scrolling looked on a real terminal:
| https://i.imgur.com/S44JaCh.mp4
|
| This is the Falco 5220e terminal emulated by MAME. It's running
| the vttest tool.
| rbanffy wrote:
| It looks awesome (would be nicer if it could be sped up,
| however).
| FullyFunctional wrote:
| Even better if the speed would ramp up and down smoothly. I
| have missed this since I used smooth scrolling CP/M computers
| in the '80es.
| bitwize wrote:
| 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.
| stuaxo wrote:
| Text mode on the PC had it, or at least VGA and probably EGA.
| NovemberWhiskey wrote:
| 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.
| bitwize wrote:
| 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.
| NovemberWhiskey wrote:
| OK sure you can do all kinds of cunning stunts with the
| CRT controller registers but that's not a capability of
| text mode in VGA per se.
| bitwize wrote:
| Sorry, should've responded to stuaxo with that.
| peterfirefly wrote:
| 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).
| toast0 wrote:
| 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
| pajko wrote:
| https://www.youtube.com/watch?v=2k1yuXiXJCY
| zabzonk wrote:
| not on the green-on-black mono monitor, as far as i can
| recall
| csdvrx wrote:
| For a good companion to smooth scrolling, check out parallax
| background scrolling:
| https://www.reddit.com/r/unixporn/comments/v2jb9o/wezterm_pa...
|
| 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.
| gorkish wrote:
| I guess I should have expected that wezterm was 3 steps ahead
| of this 2 years ago.
| jasonjmcghee wrote:
| 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
| csdvrx wrote:
| > I have never been able to do transparency or background
| images in a terminal- it's so distracting to me.
|
| 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/1
| 1w3zzj/hyprland_...
|
| The bottom part of the image has subtle movements (the wind
| effect on the grass)
| jasonjmcghee wrote:
| Don't get me wrong it looks great! Very aesthetically
| appealing. "unixporn" is appropriate.
|
| 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
| csdvrx wrote:
| > "unixporn" is appropriate.
|
| 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.
| dboreham wrote:
| The original misfeature.
| addandsubtract wrote:
| How long until we have the technology to scroll with our
| trackpads?
| Avamander wrote:
| 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.
| deathanatos wrote:
| ... such as?
|
| 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.)
| csdvrx wrote:
| 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.
| 3np wrote:
| [delayed]
| bravetraveler wrote:
| I find statements like _' incompatible with how your...'_ to be a
| bit of a smell.
|
| 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
| Waterluvian wrote:
| 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.
| Dylan16807 wrote:
| 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.
| Waterluvian wrote:
| Oh that's true. It adds extra latency at the start and end
| of a scroll.
| LispSporks22 wrote:
| 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.
| djmips wrote:
| 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.
| ckdot2 wrote:
| 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.
| deathanatos wrote:
| ... it ... isn't? I too have just tested it (with `man ls`, in
| Terminal.app), and it scrolls by whole lines.
|
| (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.)
| josephg wrote:
| 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.
| Cyphonetic wrote:
| It does if you scroll fast enough, but at a certain speed it
| reverts to whole lines.
| NovemberWhiskey wrote:
| 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.
| o11c wrote:
| The TTY sequences to insert or move lines give all the
| information needed to avoid scrolling other parts of the
| screen.
|
| Like most other things in the comments here, this is addressed
| in the article.
| NovemberWhiskey wrote:
| > _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"?
| j4_james wrote:
| 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.
| mmh0000 wrote:
| 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.
| fellerts wrote:
| Same, I react viscerally when an app implements smooth
| scrolling. Fixed increments is an absolute must. It's
| interesting how different people can be.
| josephg wrote:
| On Linux? Do you hate it on macOS as well?
|
| 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.
| zh3 wrote:
| 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)
| toast0 wrote:
| 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.
| 127361 wrote:
| 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.
| zh3 wrote:
| Totally with you; first thing on a new system is hit the
| "accessibilty" settings to disable features/improve latency.
|
| There's also the pointless visual distractions (e.g. firefox
| blue flash) even after killing web page animations,
| amelius wrote:
| You need to have a realtime OS to make it truly "smooth".
| Pinus wrote:
| 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?
| junon wrote:
| 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).
| toast0 wrote:
| 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. :(
|
| [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...
|
| [4] http://www.osdever.net/FreeVGA/vga/crtcreg.htm#08
| junon wrote:
| Oh wow thanks, these are great links!
| aragonite wrote:
| 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.
| dark-star wrote:
| 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
| aragonite wrote:
| 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.
| baal80spam wrote:
| Scrolling feels completely different with smooth scrolling
| setting on and off, when you use mouse wheel to scroll. I
| always keep it off.
| hibbelig wrote:
| 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.)
| aragonite wrote:
| > 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!
| hibbelig wrote:
| I just did a quick experiment, that's all.
| Tyriar wrote:
| 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.
| hibbelig wrote:
| > _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)?
| m463 wrote:
| Somehow I wonder if there's a 60fps type enhancement here. the
| smooth scrolling looks jerky.
|
| 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.
| 7sidedmarble wrote:
| 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'
| hibbelig wrote:
| I wasn't able to get smooth scrolling on Terminal.app nor
| iTerm2. But I would love to.
| NelsonMinar wrote:
| 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.
| MisterTea wrote:
| Never did I sit there thinking, you know what would make this
| terminal experience better? Credits.
| alberth wrote:
| Ted Unangst
|
| 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...
___________________________________________________________________
(page generated 2024-01-04 23:01 UTC)