Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!husc6!think!ames!ucbcad!ucbvax!LF-SERVER-2.BBN.COM!jr From: jr@LF-SERVER-2.BBN.COM (John Robinson) Newsgroups: comp.emacs Subject: Re: GNU emacs with X displaying is slow also (was Re: Termcap entries) Message-ID: <8707081533.AA27187@ucbvax.Berkeley.EDU> Date: Wed, 8-Jul-87 11:33:52 EDT Article-I.D.: ucbvax.8707081533.AA27187 Posted: Wed Jul 8 11:33:52 1987 Date-Received: Sat, 11-Jul-87 07:06:04 EDT References: <1070@h.cs.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 68 >> 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