cef@h.cs.cmu.edu (Charles Fineman) (07/08/87)
In article <8707071419.AA01369@ucbvax.Berkeley.EDU>, jr@LF-SERVER-2.BBN.COM (John Robinson) writes: > Since you are running X, why not use the built-in X support in emacs > (oops, you didn't say which emacs. This applies only to GNU.)? This > just forgets about the cost computation and sends updates all the > time. 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) 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. Perhaps I will look into it this summer... Charlie Fineman Carnegie-Mellon University cef@h.cs.cmu.edu (via seismo)
rlk@think.COM (Robert Krawitz) (07/08/87)
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^Zjr@LF-SERVER-2.BBN.COM (John Robinson) (07/08/87)
>> In article <8707071419.AA01369@ucbvax.Berkeley.EDU>, jr@LF-SERVER-2.BBN.COM (John Robinson) writes: >> > This >> > just forgets about the cost computation and sends updates all the >> > time. >> >> 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. When starting up under X, emacs has to make some assumptions to configure its redisplay function. Here are some of the relevant settings: baud_rate = 9600; min_padding_speed = 10000; I assume these disable all padding. Good. fix_screen_hook = xfixscreen; clear_screen_hook = XTclear_screen; clear_end_of_line_hook = XTclear_end_of_line; ins_del_lines_hook = XTins_del_lines; change_line_highlight_hook = XTchange_line_highlight; insert_chars_hook = XTinsert_chars; write_chars_hook = XTwrite_chars; delete_chars_hook = XTdelete_chars; These are the hooks that do most of the update work. Indeed, the X server is expected to be able to do insert/delete lines. The code in XTins_del_lines() generates bitblt operations (pixel copies and clears) to accomplish this. On my Sun 3/50, they are lightning fast. This is true even thought the 68020 is the bitblt engine (I think). The uVax bitblt code must be poorly written. scroll_region_ok = 1; /* we'll scroll partial screens */ char_ins_del_ok = 0; /* just as fast to write the line */ line_ins_del_ok = 1; /* we'll just blt 'em */ (Here is what tripped me up before. I thought line_ins_del_ok was set false.) fast_clear_end_of_line = 1; /* X does this well */ So there are the major update functions used by emacs under X. dont_calculate_costs = 1; This must cause redisplay to make some default choices about when to insert/delete versus when to redraw. I stopped reading code at this point. The upshot of all this is that the display driver for X makes one set of choices which can't possibly be right for all servers. Since the project Athena folks also use uVaxes a lot, they must have graphics hardware. Unfortunately, the above is all C code, so the relevant variables are not accessible from the editor at run time; else you could change the updating behavior to be right for you server. Or if you are willing to recompile, edit these code lines. If you are really ambitious, set up some config.h variables to control this better, or make it accessible at run time as you hinted. >> Perhaps I will look into it this summer... I hope I have gotten you started on the right foot. /jr