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