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