From xemacs-m  Wed Sep  3 05:26:57 1997
Received: from gol1.gol.com (gol1.gol.com [202.243.48.4])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id FAA01377
	for <xemacs-beta@xemacs.org>; Wed, 3 Sep 1997 05:26:55 -0500 (CDT)
Received: from pentagana.camelot.jp (tc-3-179.tokyo.gol.ne.jp [203.216.9.179])
	by gol1.gol.com (8.8.7/8.8.7) with ESMTP id TAA21919;
	Wed, 3 Sep 1997 19:26:53 +0900 (JST)
Received: (from jhod@localhost)
	by pentagana.camelot.jp (8.8.6/8.8.6) id TAA02278;
	Wed, 3 Sep 1997 19:19:42 +0900
To: xemacs-beta@xemacs.org, jpetersn@wsj.dowjones.com
Subject: Re: Enhanced design for XEmacs redisplay
References: <340BAEC5.7B1638@nrs.dowjones.com>
From: jareth@camelot-soft.com (P. E. Jareth Hein)
In-Reply-To: Joel Peterson's message of "Tue, 02 Sep 1997 02:14:29 -0400"
Mime-Version: 1.0 (generated by tm-edit 1.1.1.1)
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Gnus v5.4.64/XEmacs 20.3(beta18) - "Bratislava"
Date: 03 Sep 1997 19:19:42 +0900
Message-ID: <ohrab6wvgh.fsf@pentagana.camelot.jp>
Lines: 26

Joel Peterson <jpetersn@wsj.dowjones.com> writes:

> A partial description of an enhanced redisplay for XEmacs is located at
> the following URL:
> 
> http://www.geocities.com/SiliconValley/Peaks/3639/new-redisplay.txt
> 
> A new version of this document will appear in the next couple of days as
> I finish working out the algorithm to detect opportunities for scrolling
> optimization.

Hurm... One of the things I've been thinking would be a good speedup
for several pieces of code is a per-buffer start-of-line cache.
Besides speeding up redisplay, it would also provide a general speed
up under MULE. The bytind<->bufbyte conversions require a known
location to reference from when searching for a valid position, and a
nearby known linebreak would be perfect for this.  I'm not sure how
this would tie into your rune cache, but if you felt like integrating
this as well...

I'm just to lazy (and swamped with other minutae) to do anything about 
it myself at the moment...

-- 
Jareth Hein
jareth@camelot-soft.com

