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

[Micah Cowan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Jones wrote:
> I was evaluating tmux over the weekend and though I'm not prepared to
> switch any time soon, I couldn't help but notice that tmux's scrolling
> in vertical split screen mode is both very fast and devoid of the
> annoying artifacts & flickering that I see in gnu/screen.
> 
> I fact, with tmux, you can split the screen 3-4 times each way and the
> scrolling doesn't slow down and remains visually just as smooth as if
> there were only one "window".
> 
> In both cases, I am running screen & tmux on top of a 256-color capable
> xterm, with TERM='screen-256color'.
> 
> Does this mean that tmux sacrifices something else, or could the tmux
> code/solution be be adapted to screen?

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.

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.

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.

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.

(I've Cc'd Nicholas in case he has anything to add)

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkp/xTIACgkQ7M8hyUobTrGCYQCfU9je2iRMQP1xD3SrYFgcnOw8
AVMAn12JjG6sNPWYbRQ+3rAdkidgffFW
=cynz
-----END PGP SIGNATURE-----