bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16594: 24.3.50; very slow redraw when resizing windows horizontally


From: Darren Hoo
Subject: bug#16594: 24.3.50; very slow redraw when resizing windows horizontally
Date: Sun, 09 Feb 2014 06:43:18 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (darwin)


> 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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]