From xemacs-m  Wed Sep  3 15:00:07 1997
Received: from sb2inet2.dowjones.com (firewall-user@[207.78.107.3])
	by xemacs.org (8.8.5/8.8.5) with SMTP id PAA17942
	for <xemacs-beta@xemacs.org>; Wed, 3 Sep 1997 15:00:07 -0500 (CDT)
Received: by sb2inet2.dowjones.com; id PAA02301; Wed, 3 Sep 1997 15:54:20 -0400
Received: from wsj.dowjones.com(143.131.186.4) by sb2inet2.sb2inet2.dowjones.com via smap (3.2)
	id xma002221; Wed, 3 Sep 97 15:54:06 -0400
Received: from localhost (wkirk.wsjie.dowjones.com) by wsj.dowjones.com (5.x/SMI-SVR4)
	id AA26910; Wed, 3 Sep 1997 15:49:28 -0400
Sender: dj409729@wsj.dowjones.com
Message-Id: <340D165C.6DDA10C2@nrs.dowjones.com>
Date: Wed, 03 Sep 1997 03:48:44 -0400
From: Joel Peterson <jpetersn@wsj.dowjones.com>
Organization: Dow Jones & Company, Inc.
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.28 i486)
Mime-Version: 1.0
To: xemacs-beta@xemacs.org
Subject: Re: Enhanced design for XEmacs redisplay
References: <340BAEC5.7B1638@nrs.dowjones.com>
		<9709022122.AA25028@mtlyell.acteon.com>
		<m23ennxi9l.fsf@altair.xemacs.org> <199709030427.FAA02027@cerise.sensei.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 
> Tibor Polgar <tibor@alteon.com> writes:
> 
> > [lots of frames are slow]
> 
> SL Baur wrote:
> 
> > [me too esp. with lots of extents]

Glynn Clements wrote:
> [large buffer really slow]

I've noticed all of these things and taken steps to correct them.  The
first step is to track the correspondence between buffers and frames and
only mark frames as changed if a buffer they are displaying has
changed.  The current redisplay marks all frames as changed on any
buffer change (even hidden buffers).  Once a frame is marked as changed,
all of the windows on that frame are candidates for redisplay and
recomputing and reoutputing the cursor; which as far as I can tell
actually happens more often than really needed.

Large buffers are slow in part because the line number is recomputed
from the beginning each time any update is done.  The real fix is to
have a cache of known line numbers (as suggested in a seperate message
by Jareth Hein jareth@camelot-soft.com).  However, a simple fix which
works often enough is to just remember the line number of the start of
the area remembered by redisplay and just invalidate it if anything in
the buffer changes prior to the start of redisplay.  There may be
additional reasons why large buffers are slow that are unconnected to
the line number issue, but those should also be obviated to the extent
possible by the new redisplay.

Extents are slow because everything between the start of an extent and
the end of an extent needs to be recomputed even for minor changes to
either the buffer or the extent.  This is especially bad when a
particular change affects multiple extents.  The new redisplay design
addresses this in part by being smarter about checking regions which
have changed only because of extent modifications.

Extents are also slow because they rely heavily on specifiers, which,
while a good idea for supporting device independence, are relatively
slow and memory intensive.  This will remain true with the new
redisplay.

-- 
Joel Peterson
Senior Programmer/Analyst
Dow Jones & Company, Inc.

