Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!think!rlk From: rlk@think.COM (Robert Krawitz) Newsgroups: comp.emacs Subject: Re: GNU emacs with X displaying is slow also (was Re: Termcap entries) Message-ID: <6234@think.UUCP> Date: Wed, 8-Jul-87 09:33:24 EDT Article-I.D.: think.6234 Posted: Wed Jul 8 09:33:24 1987 Date-Received: Sat, 11-Jul-87 03:24:57 EDT Sender: news@think.UUCP Reply-To: rlk@THINK.COM Distribution: world Organization: Thinking Machines Corporation, Cambridge, MA Lines: 60 In article <1070@h.cs.cmu.edu> cef@h.cs.cmu.edu (Charles Fineman) writes: ]I have noticed that the redisplay (under X) in GNU emacs can be ]*VERY* slow (read INEFFICIENT). This happens esspecially when I ]am scrolling. I think GNU emacs tries to be too smart in its ]refresh and as a result it makes all these contortions: shifting ]around text and the like when it would have been *much* faster to ]redraw the entire screen. (BTW setting the terminal speed w/stty ]didn't help at all) I'm well aware of this problem, but optimally fixing it is not easy. The best thing to do is to somehow set the baud rate as high as possible (using stty on the terminal will NOT work, as emacs does not use a pty when talking to X, and the X driver sets the speed to 9600, which is much too low). Setting the speed to 1000000 baud is not unreasonable. There are four other parameters that control the insert/delete behavior: ILcost, ILncost, DLcost, and DLncost. ILcost specifies the cost in units of character insert time to insert a single line, and ILncost specifies the cost of inserting additional lines (typically on a terminal the first insert will be expensive, then it will be cheap to insert more lines at the same time). DLcost and DLncost are the equivalents for line deletion. Character insert/delete is turned off under X. Line insert/delete is a capability that should be enabled, but the turnover point is dependent upon a lot of variables, such as display type, network latencies, etc. The reason that it should be enabled is that many displays are capable of fast copy, which favors insert/delete of lines. On the other hand, other displays are not capable of fast copying of bits, in which case it is probably preferable to redraw the display. Certain other displays, such as the Sun 3 (no flames, please; I say this because I am using one to write this, and the only other displays I've used are the VS100, QVSS, AED, and APA16), are so fast that it hardly matters. A useful capability, which I implemented in a debugging version of X, is for the user to be able to set these capabilities. Then you can play around with these variables, and find an optimum. I never really found the optimal point for any display, though. ]Now, I should point out that I am running on a uVax II w/o a ]graphics card so the X display driver is understandably ]not the fastest in creation, but it seems to me that in such ]a case, I should have the option of turning off the fancy redisplay. ]preferably within ELISP so I can set it in my .emacs file. This is the display that I've experimented on. Unfortunately, I don't have my testing code around, and I don't remember just where these variables are (scroll.c, perhaps?). These functions aren't hard to write. If you do this, remember to set the baud rate to something extremely high, particularly if you use your local display most of the time. ]Perhaps I will look into it this summer... RMS has rewritten the X driver, and for all I know he might have fixed this. Robert^Z