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

[Chris Jones-44]

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?

CJ


_______________________________________________
screen-users mailing list
screen-users@...
http://lists.gnu.org/mailman/listinfo/screen-users

[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-----


_______________________________________________
screen-users mailing list
screen-users@...
http://lists.gnu.org/mailman/listinfo/screen-users

[Nicholas Marriott-2]

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-----

_______________________________________________
screen-users mailing list
screen-users@...
http://lists.gnu.org/mailman/listinfo/screen-users

[Chris Jones-44]

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


_______________________________________________
screen-users mailing list
screen-users@...
http://lists.gnu.org/mailman/listinfo/screen-users

[Chris Jones-44]

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

[..]

I believe I forgot to mention that the "slowness" and "flickering" does
not occur in the rightmost pane. In other words, if I split the screen
down the middle, start a shell, and issue a pstree command in the right
pane, the screen is displayed tolerably fast as compared with the same
pstree command run in the left pane where the scrolling is atrociously
slow.

You may already be aware of this, and you may also have some idea why
this is happening but there seems to be a pattern: even if you split the
screen further down the middle and have for instance four "vertical"
panes, the one further to the right will scroll a lot faster than the
other three.

In any event, this means that a workable strategy for the time being, is
to make sure that any screen window that you will use to run something
that has demonstrated problems with scrolling is always in the rightmost
pane. I've tried it with gdb in the left pane and any other stuff that I
needed to take a look at always in the right pane and this worked quite
well.

Also leads me to wonder is this is xterm-specific or if the same problem
also occurs when running on top of other emulators.

As I said earlier, I won't be able to do much in the way of intelligent
testing, and even less figure out what is happening and try to provide a
fix, but I'll keep an eye open and document what I see, in the event it
might be useful.

CJ


_______________________________________________
screen-users mailing list
screen-users@...
http://lists.gnu.org/mailman/listinfo/screen-users