GNU bug report logs - #16594
24.3.50; very slow redraw when resizing windows horizontally

Previous Next

Package: emacs;

Reported by: Darren Hoo <darren.hoo <at> gmail.com>

Date: Thu, 30 Jan 2014 08:03:01 UTC

Severity: normal

Tags: unreproducible

Merged with 17124

Found in version 24.3.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Darren Hoo <darren.hoo <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16594 <at> debbugs.gnu.org
Subject: bug#16594: 24.3.50; very slow redraw when resizing windows horizontally
Date: Sun, 09 Feb 2014 06:43:18 +0800

> Yes, under the current design, because the user can invoke
> (set-input-interrupt-mode nil). I don't know why we're exposing that
> capability to the user.

Thanks a lot for the information I now understand this finnally.

So the problem is that it is set to nil on NS. I think it should
be changed to t.

Firstly it can make the symptom in this bug report ocurr less often,
secondly it makes C-g work more pleaseantly, like M-! sleep 1000 I
can quit with C-g almost instantly using interrupt-input driven
style, while I have to wait for 1~2 seconds using the polling method.

So this is the trivial change:

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2014-02-07 03:25:52 +0000
+++ src/nsterm.m	2014-02-08 20:41:45 +0000
@@ -4215,7 +4215,7 @@
   block_input ();
 
   baud_rate = 38400;
-  Fset_input_interrupt_mode (Qnil);
+  Fset_input_interrupt_mode (Qt);
 
   if (selfds[0] == -1)
     {

There is another thing that causes the hiccup though less often,
randomly but really annoying. After spent some time tracking down I
find out that it is the display_hourglass thing, I don't understand
what this is really used for. I checked it out on GNU/Linux I don't
see any visible feedback while Emacs is busy.

And (setq display-hourglass nil) totally makes the problem go away.

I still quite don't understand why redisplay takes more than 3 even
6 seconds when SIGALRM comes and the handler is not doing anything
expensive, redisplay only takes about 0.0001 seconds normally.

I think I still have something that I don't quite catch here.





This bug report was last modified 4 years and 259 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.