Xref: utzoo gnu.emacs:1421 gnu.emacs.bug:1058 comp.emacs:6689
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!think.com
From: rlk@think.com (Robert Krawitz)
Newsgroups: gnu.emacs,gnu.emacs.bug,comp.emacs
Subject: Re: Scrolling in GNU emacs
Message-ID: <27123@news.Think.COM>
Date: 16 Aug 89 17:33:57 GMT
References: <8914@cbnews.ATT.COM>  <1989Aug14.153236.13162@talos.uucp>
Sender: news@Think.COM
Reply-To: rlk@think.com (Robert Krawitz)
Followup-To: gnu.emacs
Organization: Thinking Machines Corp., Cambridge MA
Lines: 36
In-reply-to: kjones@talos.uucp (Kyle Jones)

In article <1989Aug14.153236.13162@talos.uucp>, kjones@talos (Kyle Jones) writes:
]Tom Horsley writes:
] > You would think that if a terminal has scrolling regions, it would
] > *always* be faster to scroll, but it does some sort of cryptic computations
] > that wind up deducing it is faster to redraw the whole screen than to
] > scroll:
]So if Emacs is making the wrong decision between scrolling and redrawing
]then more than likely it's been given incorrect (or no) information to
]work with.

Gnu Emacs does make the wrong decisions when it comes to scrolling.  The
problem is that the emacs terminal driver was designed to work with
fixed-rate terminals with scrolling implemented in microcode or hardware
that is much faster than repainting the screen.  The X interface, at
least in versions 17 and 18, has stubs which are called by the terminal
driver; i. e. X simply replaces some of the low-level terminal driver
modules (this is even how the mouse is implemented).

I did some experiments several years ago with setting various
parameters, many of which are not user accessible (I wrote setter
functions for them).  My conclusion is that the right behavior is very
hard to determine.  Setting the baud rate to something much higher, like
1000000 rather than 9600, definitely helps substantially.  There are
other internal parameters (whose names I have long since forgotten) that
seem to penalize scrolling compared to repainting.  The problem is that
different displays have different characteristics, and the differences
are great enough to have substantial impact on a big emacs window (such
as 89 lines of 160 columns split horizontally into two windows).  It
also knows nothing about bitblt-type operations, which could save a lot
of time in these situations.  I hope RMS is investigating it for Version
19; it would be unfortunate if this wasn't improved.  On a color Sun,
the current scrolling behavior is dreadfully slow.
-- 
ames >>>>>>>>>  |	Robert Krawitz 	245 First St.
bloom-beacon >  |think!rlk				Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111