From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Display slowness that is painful Date: Fri, 03 Feb 2006 11:00:22 +0100 Message-ID: References: <87slr5c78p.fsf@stupidchicken.com> <877j8fx43q.fsf@stupidchicken.com> <87mzhaqp7p.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 1138987578 9865 80.91.229.2 (3 Feb 2006 17:26:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 3 Feb 2006 17:26:18 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 03 18:26:13 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 1F54gk-0004oq-8c for ged-emacs-devel@m.gmane.org; Fri, 03 Feb 2006 18:25:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F54ju-0001af-W7 for ged-emacs-devel@m.gmane.org; Fri, 03 Feb 2006 12:28:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F4xvF-0004xN-By for emacs-devel@gnu.org; Fri, 03 Feb 2006 05:12:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F4xuQ-0004QG-SN for emacs-devel@gnu.org; Fri, 03 Feb 2006 05:11:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4xoF-0002iV-4U for emacs-devel@gnu.org; Fri, 03 Feb 2006 05:04:55 -0500 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1F4xnA-00073h-Tp; Fri, 03 Feb 2006 05:03:48 -0500 Original-Received: from [195.41.46.237] (helo=pfepc.post.tele.dk) by mx20.gnu.org with esmtp (Exim 4.52) id 1F4xkz-0001DX-Jz; Fri, 03 Feb 2006 05:01:33 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepc.post.tele.dk (Postfix) with SMTP id 9B5FC26282E; Fri, 3 Feb 2006 11:01:21 +0100 (CET) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Fri, 03 Feb 2006 00:04:01 -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:49960 Archived-At: "Richard M. Stallman" writes: > Thanks for writing that optimization. I figured some such simple fix > would be possible. Please install your fix. > > What my experience has taught me is that cases of anomalous gross > slowness often have a simple fix. Thus, before taking up the > difficult question of whether major surgery is justified, it's a good > idea to look for a fix like this one which does the job with a band-aid. > > (Yi-dong found a different way to apply a band-aid, but it assumes > that the file was visited in Image mode, so it doesn't solve the whole > problem. This change does, I think.) While debugging this, I noticed that sometimes redisplay was (quite) fast, while at other times, it was VERY slow. I traced this to emacs starting to process SELECTION_REQUEST_EVENT events after each redisplay round -- and consequently doing another redisplay... So in effect it never seemed to reach a point where it would actually update the display. Doing M-: (setq redisplay-dont-pause t) RET made redisplay much snappier in this specific case. Perhaps we should have some form of timer associated with the (default) redisplay-dont-pause == nil case, so that even if input_pending, we will still update the display if the last completed redisplay happened more than, say 2 seconds ago. -- Kim F. Storm http://www.cua.dk