On Wed, Feb 08, 2012 at 03:47:00PM +0100, Aurélien Aptel wrote:
> On Wed, Feb 8, 2012 at 2:49 PM, ilf <ilf_AT_zeromail.org> wrote:
> > I am running the same tmux session in both rxvt-unicode and st next
> > to each other. The drawing speed of st does indeed feel better than
> > before, but it's still way slower than rxvt in everything I have
> > tried. This is one of the issues still holding me back from
> > switching to st as my main terminal emulator. Do other terms have
> > magic in their rendering code for extra speed?
>
> It's strange because fast scrolling in tmux seems to be the only case
> where st is unbearably slow. I've tried to profile this [1] but I've
> not found anything conclusive...
I don't think st does anything wrong (I very much like the dirty line
and last_draw_too_old modifications). XTerm is already slower than st in
some cases since it doesn't skip renderings.
To see what urxvt does differently I actually looked at the urxvt source
code (which is something I kinda regret - it's damn UGLY).
From what I found I would suspect that what makes urxvt fast for the
tmux scrolling case is that it optimizes scrolling by using XCopyArea
when it can. To see the difference without this optimization you only
need to start urxvt with something like
urxvt -tr -sh 10 -fg grey70 -bg grey10
At least on this computer urxvt can't handle the burst in tmux any more.
The simple "cat 10000lines" took urxvt more than 4 seconds and st only
somewhere around .1 second.
To get st to behave a little better in the tmux case I changed a few
things in run() around (no optimized scrolling, just some tweeks to
Auréliens optimizations). With these changes it's okay to use a relative
high value for DRAW_TIMEOUT. The trade off is a slow refresh rate in
case of a burst. In case someone wants to try this I attached a patch to
revision 228.
--
Eckehard Berns
Received on Thu Feb 09 2012 - 17:43:07 CET