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

[Nicholas Marriott]

Hi

I haven't tested but I suspect this is probably the reason tmux is faster (from
tty_redraw_region in tty.c):

        /*
         * If region is >= 50% of the screen, just schedule a window redraw. In
         * most cases, this is likely to be followed by some more scrolling -
         * without this, the entire pane ends up being redrawn many times which
         * can be much more data.
         */
        if (ctx->orupper - ctx->orlower >= screen_size_y(s) / 2) {
                wp->flags |= PANE_REDRAW;
                return;
        }

Because entire pane redraws happen once after all buffered data has been
consumed, this has the effect of redrawing the entire pane once for however
many lines were scrolled in that read(2), rather than once for each line.

This works well over a short link but is obviously fairly naive, something
speculative or based on a timer might be more effective over a longer
link. Higher network latency will mean less scrolling buffered so more redraws
and (visibly) slower scrolling.

You can swap windows out of and into panes with the break-pane and swap-window
commands. No way to move a window in yet (without swapping it) but that would
be trivial, it just needs someone to write it or hassle me for it.

Nicholas


On Sun, Aug 09, 2009 at 11:58:58PM -0700, Micah Cowan wrote:
> -----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-----