From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Display slowness that is painful Date: Thu, 02 Feb 2006 00:55:38 -0500 Message-ID: <87mzhaqp7p.fsf@stupidchicken.com> References: <87slr5c78p.fsf@stupidchicken.com> <877j8fx43q.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138859762 26547 80.91.229.2 (2 Feb 2006 05:56:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 2 Feb 2006 05:56:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 02 06:55:57 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F4XRh-000238-EW for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2006 06:55:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4XUn-0003YR-GT for ged-emacs-devel@m.gmane.org; Thu, 02 Feb 2006 00:59:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F4XUe-0003YA-29 for emacs-devel@gnu.org; Thu, 02 Feb 2006 00:58:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F4XUc-0003Xw-HN for emacs-devel@gnu.org; Thu, 02 Feb 2006 00:58:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4XUc-0003Xt-C2 for emacs-devel@gnu.org; Thu, 02 Feb 2006 00:58:54 -0500 Original-Received: from [18.95.6.38] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F4XTL-0007JG-I5; Thu, 02 Feb 2006 00:57:35 -0500 Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 7272B1E429B; Thu, 2 Feb 2006 00:55:38 -0500 (EST) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Wed, 01 Feb 2006 23:16:28 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49917 Archived-At: "Richard M. Stallman" writes: > This is *really* not the time to make changes in redisplay. > > Yes it is. Even if we had started the pretest already, > we would fix this bug. Or what are pretests for? Managers of successful software projects often make the conscious choice to postphone resolving bugs whose "fixes" can introduce even more serious bugs while conferring limited benefits. (And they seem to be able to actually make releases...) If a workaround can be found that avoids this problem without changing redisplay code, I think it is preferable. In this particular case, having looked through the relevant redisplay code, I don't see any apparent code stupidity going on. It's simply the case that, in this file, the first "newline" takes place 340,000 characters in. The normally negligible delay from displaying glyphs in octal format (v.s. unibyte-display-via-language-environment) is magnified by this amount. The redisplay engine has to scroll through the entire "line" to check for overlays, text properties, etc., and this seems to be unavoidable. Of course, if you can point out a specific redisplay optimization that we're missing, I'm all ears.