Re: redisplay-tty.c improvements
"J. Kean Johnston" <jkj(a)sco.com> writes:
One of the other advantages of terminfo is that you can use more
than two parameters to any given capability. You can only do that in
termcap if you roll out own tparam(). There are a few capabilities
of great use that use more than 2 parameters, most notably the wind
cap. In the current redisplay stuff we get the scrolling region
(csr) cap but dont ever use it, and we dont even retrieve the wind
cap. Both of these can be used to speed up redisplay dramatically on
a TTY, and I would like to make such improvements.
However, the redisplay stuff seems to be a feared piece of code and
folks are loathsomet o change it.
There is no opposition to changing the redisplay stuff, it's just that
noone has had the motive, the knowledge, and the willingness required
to make the improvements. Our current TTY code is utter junk,
prototype code written only to be replaced with something better.
Except that the replacement never happened.
So, before I go do a whole bunch of work, does anyone have comments,
questions or suggestions? Look forward to hearing them
Here is an interesting article by Chuck Thompson, the guy who wrote
our current redisplay engine:
From: cthomp(a)xemacs.org (Chuck Thompson)
Subject: Re: Display speed on ttys (was Re: Bench Marking XEmacs)
Date: Thu, 21 Nov 1996 09:50:20 -0600
Newsgroups: comp.emacs.xemacs
Message-ID: <199611211550.JAA16841(a)xemacs.cs.uiuc.edu>
Vladimir> Is it technically feasible to keep two versions of the
Vladimir> display engine (one general and the other tty-optimised)
Vladimir> and use the one that's appropriate for the current
Vladimir> frame?
The redisplay engine is divided into three parts. The largest by far
is the part that figures out what the display should currently look
like and creates data structures representing that display. The
second part compares the structures representing what is currently
displayed with the new structures representing what should be
displayed and calls output routines as apropriate to make them
identical. The third part is the actual output routines. There are
separate routines for each type of output system XEmacs currently
supports. Currently that means X and tty's. With very few exceptions
the first and second parts of the display engine have no idea what
type of device they are working with. To port the XEmacs display
engine to something new such as, say, Windows 95, a new file
redisplay-win95.c would need to be created. Almost nothing else would
need to be done.
Current sizes of those three parts:
first 243458 redisplay.c
second 39003 redisplay-output.c
third 42711 redisplay-tty.c
67265 redisplay-x.c
Getting back to your question. The only part that really requires any
work to massively speed up the tty output performance is the middle
part, redisplay-output.c. A few new routines would need to be added
to redisplay-tty.c but those are pretty straight forward.
redisplay-output is currently optimized to figure out what part of a
given line has changed and to only output that part of the line. For
X displays this works just fine and in fact in a variable height line
it gets really messy to do anymore. tty's are not variable height,
however, and there display routines are designed around the assumption
that large blocks of unchanged text are not redrawn but scrolled to
their new position. You should be able to see the problem now.
Efficient tty updating needs to work on multiple line blocks but
redisplay-output only looks at single lines.
The fix is to calculate a hash value for each line in both the current
and desired display structures, use that info to find blocks of lines
which have just been shifted up or down and not actually changed
otherwise and then use tty scrolling routines to move them rather than
redrawing them. This optimization should probably actually be
triggered when the number of lines in the current and desired displays
are equal rather than based on whether the output display is a tty or
not. Though some mechanism then needs to be present to disallow it
since block scrolling on some X devices is actually slower than just
redrawing everything.
There you have it. Go for it. I really, really wish I had time to
implement it, but I don't.
-Chuck