From xemacs-m  Tue Sep  2 23:36:11 1997
Received: from server.sensei.co.uk (server.sensei.co.uk [193.132.124.5])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id XAA29584
	for <xemacs-beta@xemacs.org>; Tue, 2 Sep 1997 23:36:09 -0500 (CDT)
Received: from cerise.sensei.co.uk (glynn@muvies.demon.co.uk [158.152.66.14]) by server.sensei.co.uk (8.8.5/8.8.2) with ESMTP id FAA31802 for <xemacs-beta@xemacs.org>; Wed, 3 Sep 1997 05:35:47 +0100
Received: (from glynn@localhost) by cerise.sensei.co.uk (8.8.5/8.8.2) id FAA02027; Wed, 3 Sep 1997 05:27:10 +0100
Date: Wed, 3 Sep 1997 05:27:10 +0100
Message-Id: <199709030427.FAA02027@cerise.sensei.co.uk>
From: Glynn Clements <glynn@sensei.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: xemacs-beta@xemacs.org
Subject: Re: Enhanced design for XEmacs redisplay
In-Reply-To: <m23ennxi9l.fsf@altair.xemacs.org>
References: <340BAEC5.7B1638@nrs.dowjones.com>
	<9709022122.AA25028@mtlyell.acteon.com>
	<m23ennxi9l.fsf@altair.xemacs.org>
X-Mailer: VM 6.33 under 20.3 "Bratislava" XEmacs  Lucid (beta18)


Tibor Polgar <tibor@alteon.com> writes:

> I wish i could give all of you a smoking gun handloop but can't.  All
> i can say is that if i have 5 or 6 frames up, each with a different
> file visible, character input becomes dog slow.  If i then iconify
> all the frames except for the one, all is back to normal.

SL Baur wrote:

> I've experienced this too.  It tends to be most pronounced when there
> are a lot of different extents visible (as in a dired frame or a Gnus
> *Topics*/*Summary* buffer).
> 
> The symptom I see is that every visible frame appears to be redrawn
> with each keystroke.  The faster the machine, the more difficult it is 
> to see what is happening.

On the subject of things that make XEmacs `dog slow', can I add this
one:

Having a large buffer open in one window, with point near the bottom
of the buffer. The further down the large buffer point is, the slower
everything becomes.

Narrowing the large buffer to a small portion improves things. AFAICT,
the slowdown seems dependent upon the amount of `unhidden' text above
point. Changing the buffer-window correspondence so that the large
buffer is no longer visible eliminates the slowdown.

On a reasonable P120 running Linux, having point at the bottom of a
10Mb buffer causes simple operations (cursor movement, self-insertion)
to take about a second. About the only operation that doesn't slow
down is delete-backward-char.

If someone's looking at improving the redisplay code, then eliminating 
this behaviour would significantly improve things.

-- 
Glynn Clements <glynn@sensei.co.uk>

