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@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
