Scroll in terminal emulator (urxvt) like in console

brianb · 2017-02-09 00:35:54

In the Arch Linux console, when you scroll through pages using a pager like less, the screen changes at a quick but non-instantaneous rate, so that scrolling actually looks like scrolling: you can see the text move up/down. I find this visually very appealing, and I'm wondering if it's possible to reproduce this behavior in a terminal emulator like urxvt.

One problem I'm having, if you can't already tell by my confusing/uninformative thread title, is that I don't know exactly how to phrase what I'm trying to achieve. (I'm not sure if "scroll" is the right term for what I'm talking about, nor whether "slow scroll" properly describes the behavior.) In any case, I've had no luck with Google, and I've also scoured the urxvt man page to no avail.

I'm not sure if it's a urxvt option that I need to set (assuming one exists), or what.

I also thought that perhaps it's specific to less (maybe an option that the console uses but urxvt doesn't?). One reason I thought it might be less-specific is that I noticed that, in console, if I press shift + pg up/down to view previous text, the scroll behavior is different: the screen changes instantaneously. In other words, there's a difference in console between scrolling with pg up/down vs. scrolling in less.

However, the same scroll behavior, in console, works with more as well, so in the end I think it's a console vs. urxvt difference.

Any ideas?

Trilby · 2017-02-09 00:41:53

I get the same behavior in less in urxvt and a tty. How do you "scroll" in less? Are you using page up/down keys? Are you just holding a cursor (e.g. up/down)?

brianb · 2017-02-09 00:46:45

I'm talking scrolls that move the page more than one line, e.g. a full-page scroll with f or half-page scroll with d. Example:

Console

1. Log into console.
2. Run "man man".
3. Hit "f" several times to scroll down several pages.
4. See the text shoot up the page -- quickly but identifiably.

vs.

urxvt

1. Open a terminal instance.
2. Same as above.
3. Same as above.
4. See the page change instantaneously -- no identifiable text movement.

Trilby · 2017-02-09 01:01:28

Thanks - that's more clear. Unfortunately I still can't replicate your results. It looks identical, and in both cases it is an instantaneous move.

In either case, is the the bottom/remainder of the man page text left on the screen after you exit your pager? If so, it may be that one of the two is not using the curses "alt screen".

What does `echo $TERM` return in each environment?

brianb · 2017-02-09 01:14:46

Trilby wrote:

is the bottom/remainder of the man page text left on the screen after you exit your pager?

For console, yes; for urxvt, no.

Trilby wrote:

If so, it may be that one of the two is not using the curses "alt screen".

I'm not sure what "alt screen" is. Can you provide more info?

Trilby wrote:

What does `echo $TERM` return in each environment?

For console, it's "linux", and for urxvt, it's "rxvt-unicode-256color".

Trilby · 2017-02-09 01:31:36

brianb wrote:

I'm not sure what "alt screen" is. Can you provide more info?

I can try - but I know this only pretty superficially. Terminal programs come in two "flavors". The first are programs that work in a purely serial/sequential manner. Each line that is printed pushes all other output "up". These programs rarely if every move the cursor position up or back (back to the start of the line is a not uncommon exception especially for progress indicators: write a line, return the cursor to the start of the line, and overwrite it with the next line). These are programs that would run just as well on true serial termials (e.g. teletypes). This flavor includes programs like ls, ps, awk, sed, cat, just to name a few.

The other flavor takes over the screen and frequently draws output at all different locations often to simulate a scrolling "text window" perhaps with a status bar, or menus. This would include most editors (vim, nano, but not ed), as well as htop, more, less, and many others.

Generally this latter flavor of program runs in what is called an "alt screen" or alternate screen which I believe is provided by the (n)curses library. If - for any reason - the (n)curses alt screen cannot be used, most of these programs fall back to a more "manual" mode of moving the cursor around to draw all the things they need to draw. When you have an alt screen available and start one of these programs, your console mode switches to the alt screen and everything is drawn there - so when you quit the program, you are back at your original command prompt. If no alt screen is available (or cannot be used) then when you quit the program you get a command prompt, but it is below the remnants of whatever was just drawn by the pager/editor/whatever as it was using the same screen not an alt screen.

It's perfectly feasible that the "manual" drawing on the main screen would cause a line-by-line redraw that is perceived as the scroll you describe where as the (n)curses alt screen moves "instantaneous" not drawing every intermediate line.

I believe there are ways to prevent the use of the alt screen for some programs, but I do not recall how, and my googling is failing me at the moment.

But the difference between your console and X11 terminal emulator is likely that the console does not have alt screen capabilities. I beleive this would be dependent on your graphics driver and/or whether you are using kernel mode setting (KMS).

EDIT: The above may not actually be right. I just found when I set MANPAGER=less I did get the same results you describe in the tty but not in urxvt under X. Normally I use MANPAGER=vimpager. Also, exporting LESS="-d" which *should* inhibit the use of the alt screen doesn't change the results.

brianb · 2017-02-09 01:46:05

Thanks! That's very informative, and your speculation certainly sounds reasonable. However, a couple quick tests make me think that the "scrolling" behavior and the alt screen stuff (where quitting still leaves the text on the screen) may not be so related.

First, I discovered here that you can disable alt screen in less my setting "export LESS='-X'". I tried that, and indeed, in urxvt, when I quit less, the text remains on the screen; however, scrolling in less does not reproduce the perceivable scroll behavior.

Second, I tested a couple other programs in console which use alt screen, like mutt and vim (when I quit mutt/vim, the text remains); however, they do not produce the perceivable scroll behavior, e.g. when I scroll a half page in mutt or full page in vim.

So, in the end, maybe it's only pagers that do it. Odd.

Edit: I just read your edit -- glad to see you've managed to reproduce the behavior, and that I'm not crazy!

Last edited by brianb (2017-02-09 01:47:04)

Steef435 · 2017-02-09 02:03:27

This intrigues me. I do believe it has to do with the scrolling speed of the framebuffer (which is so slow that you can actually perceive it, it can't keep up with the input buffer).

For instance, if I execute something like ls -al /usr/bin, I also notice the scrolling behaviour on the console, while ls definitely isn't using curses. The terminal emulator is just "faster" at scrolling.

I think the reason is something like this: by default, less "repaints" the screen by scrolling instead of just clearing the screen and reprinting line by line. Because it uses this scrolling, which is slow, the repaints appear slow. Which is why we can perceive it.

The hunch for all this: try running less with the -c option (which forces full screen repaints from top line down, see man less). The "smooth scrolling" doesn't appear in the console when using this option on my end.

Terminal emulators aren't necessarily a lot faster (well, they are) but they also use some dirty tricks. Take a look at the man page of urxvt: options like jumpScroll (just scroll once every screen height instead of every line) and skipScroll (visibly scroll a maximum of ~60 times per second, "skip frames") are on by default, which is why the emulators appear faster. Disabling options like these on xterm had some effect for me, I can now see the scrolling, but it still isn't as slow as with the virtual console.

In other words, you need a crappy emulator. Or one which allows you to specify a delay per line scroll. I don't know of one.

brianb · 2017-02-09 03:45:45

I think you might be onto something:

ls -l /usr/bin | less    # visible scroll when hitting ffff in console
ls -l /usr/bin | less -c # no visible scroll

So same behavior for me that you report.

Steef435 wrote:

In other words, you need a crappy emulator. Or one which allows you to specify a delay per line scroll. I don't know of one.

Yup, too bad.

Steef435 wrote:

"smooth scrolling"

Aha, that's the term I was looking for. I recall now that Firefox has a "smooth scrolling" option that does exactly this. I'm actually surprised, now that I think about it, that no emulator (that I know of) offers such an option.

Last edited by brianb (2017-02-09 03:47:26)

seth · 2017-02-09 19:57:42

Steef435 wrote:

In other words, you need a crappy emulator. Or one which allows you to specify a delay per line scroll. I don't know of one.

phosphor (xscreensaver)

Arch Linux

#1 2017-02-09 00:35:54

Scroll in terminal emulator (urxvt) like in console

#2 2017-02-09 00:41:53

Re: Scroll in terminal emulator (urxvt) like in console

#3 2017-02-09 00:46:45

Re: Scroll in terminal emulator (urxvt) like in console

#4 2017-02-09 01:01:28

Re: Scroll in terminal emulator (urxvt) like in console

#5 2017-02-09 01:14:46

Re: Scroll in terminal emulator (urxvt) like in console

#6 2017-02-09 01:31:36

Re: Scroll in terminal emulator (urxvt) like in console

#7 2017-02-09 01:46:05

Re: Scroll in terminal emulator (urxvt) like in console

#8 2017-02-09 02:03:27

Re: Scroll in terminal emulator (urxvt) like in console

#9 2017-02-09 03:45:45

Re: Scroll in terminal emulator (urxvt) like in console

#10 2017-02-09 19:57:42

Re: Scroll in terminal emulator (urxvt) like in console

Board footer