Re: Scrolling performance in vertical split-screen mode - screen vs. tmux

[Chris Jones]

On Mon, Aug 10, 2009 at 02:58:58AM EDT, Micah Cowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

[..]

> I haven't looked at the tmux code. But I was speaking with Nicholas
> Mariott, tmux's author, about the (very recently merged) vertical split
> code, and I did not get the impression from them that he was doing
> anything special. In particular, he indicated that they, too, have to
> redraw the entire region on every scroll, and that they weren't using
> the special xterm rectangular-scrolling regions. This matches what I'm
> seeing, as for my part I do see the artifacts and flickering.
> 
> But he also indicated that (to him at least) the slowdown wasn't
> annoying unless you were on ssh "over 20 hops away". I did a quick test
> just now with a simple increment-a-number-and-print-it infinite loop,
> and it does seem that tmux's scrolling is somewhere around 2.5 times
> faster than ours.
> 
> The obvious explanation would seem to be either that we're spending more
> characters to do the redraws than tmux is, or we spend more time
> (processing?) between sending the character sequences.

Something I had not really noticed is that the "less" pager (invoked via
man xterm in my case) scrolls considerably more slowly under gnu/screen
than tmux, when running full-screen on a "large" (232x85) 256 color
xterm _even if I don't split the screen_ - so much so that I can just
about manage to freeze/unfreeze the display a couple of times via Ctrl-S
Crl-Q within the timeframe of a one page-scroll, or briefly follow one
particular line for a second or so and read its first few words. 

Under tmux, or on a "native" xterm, scrolling down one page happens so
fast that I can't see it happening.

The "man xterm" is just an example, line-mode stuff such as "ls -alch"
behaves likewise.. much slower scrolling when running under gnu/screen,
for some reason, vim, mutt, Elinks.. do not appear to be affected.

I'm beginning to wonder if I have gnu/screen misconfigured.

[naturally, this may be irrelevant to the slowness of gnu/screen's
vertical split-screen mode - which makes the already slow scrolling I
describe above even slower.. by a factor of 2 or 3, at a glance]

> The bad news is, it's not one of the top priorities, and there are
> very few developers, all of whom have very little time to give. I
> doubt that this will be addressed soon. I know that for my part, the
> inefficiency of the vertical splits is a major reason why I still
> prefer using two side-by-side terms attached to the same session most
> of the time.

Probably only of interest for users like me, who mostly use text-mode
applications and whose interest in gnu/screen (or tmux) is limited to
what amounts to a bare-bones "window" manager.

> If someone _would_ like to help deal with it, I suspect that using
> Teseq (a program I wrote to help debugging Screen stuff:
> <http://www.gnu.org/software/teseq>) would help for comparing the
> output from the two programs (as recorded by a program such as the
> "script" command), and also the timings between sequences.

Wish I had the programming background to help... :-)

> On a side note, I'll point out that one thing that disappointed me
> about the current operation of the left-right splits in tmux (they
> call those ones the "horizontal" splits) is that you can't swap
> windows around in the splits the way you can with screen: in tmux, the
> splits live _under_ the window. You can break a split into discreet
> windows, but AFAICT you can't pull a window into a new (or existing)
> split. For me, that's pretty much a deal-breaker, as my usage involves
> swapping windows in and out of the views pretty frequently. However,
> Nicholas seemed to think screen's approach may be better, and sounded
> like he might move toward that model in the near future.

Bit of a show-stopper for me as well.

Thanks for your comments.

CJ