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

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

[Darren Hoo]

emacs -q
(scroll-bar-mode 'nil)
C-x 3

then try to resize the windows using mouse several times and emacs
redisplay is so slow that you can notice the fringes besides the drag
handle is repainted from top to bottom frame by frame.

profiling shows `read-event' takes much of the time, is this the real
cause?

- command-execute                                                 207  98%
 - call-interactively                                             207  98%
  - mouse-drag-vertical-line                                      202  96%
   - mouse-drag-line                                              202  96%
    - eval                                                        202  96%
     - track-mouse                                                202  96%
      - funcall                                                   202  96%
       - #<compiled 0x40a712ed>                                   202  96%
        - read-event                                              184  87%
         - redisplay_internal (C function)                          1   0%
            eval                                                    1   0%
  + profiler-report                                                 5   2%
- ...                                                               2   0%
   Automatic GC                                                     2   0%
+ redisplay_internal (C function)                                   1   0%


In GNU Emacs 24.3.50.81 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
 of 2014-01-29 on darren-rmbp
Repository revision: 116189 rudalics@gmx.at-20140128094537-ajntocd34vgsenh3
Configured using:
 `configure --with-ns'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ ? 1 ; 2 c ESC x r e p o r t TAB RET

Recent messages:
("/Applications/Emacs.app/Contents/MacOS/Emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils xterm time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)

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

[martin rudalics]

 > emacs -q
 > (scroll-bar-mode 'nil)
 > C-x 3
 >
 > then try to resize the windows using mouse several times and emacs
 > redisplay is so slow that you can notice the fringes besides the drag
 > handle is repainted from top to bottom frame by frame.
 >
 > profiling shows `read-event' takes much of the time, is this the real
 > cause?
 >
 > - command-execute                                                 207  98%
 >  - call-interactively                                             207  98%
 >   - mouse-drag-vertical-line                                      202  96%
 >    - mouse-drag-line                                              202  96%
 >     - eval                                                        202  96%
 >      - track-mouse                                                202  96%
 >       - funcall                                                   202  96%
 >        - #<compiled 0x40a712ed>                                   202  96%
 >         - read-event                                              184  87%
 >          - redisplay_internal (C function)                          1   0%
 >             eval                                                    1   0%
 >   + profiler-report                                                 5   2%
 > - ...                                                               2   0%
 >    Automatic GC                                                     2   0%
 > + redisplay_internal (C function)                                   1   0%

I checked in a fix such that mouse dragging a line doesn't occur
pixelwise by default.  Does this improve the behavior?  I have no idea
how to interpret the profiler report - when you drag a line it will
always be the case that most of the cpu is consumed by that.

martin

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

[Darren Hoo]

martin rudalics <rudalics@gmx.at> writes:


> I checked in a fix such that mouse dragging a line doesn't occur
> pixelwise by default.  Does this improve the behavior?  I have no idea
> how to interpret the profiler report - when you drag a line it will
> always be the case that most of the cpu is consumed by that.

I tried the fix, the behavior is worse now. Sluggishness still occurs.
While dragging the splitter and the mouse pointer are not synchronized
now, when dragging finishes while still holding the left mouse button
the mouse pointer is far away from the splitter.

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

[Stefan Monnier]

> I checked in a fix such that mouse dragging a line doesn't occur
> pixelwise by default.

That's sad.  I thought it was one of the nicest and most immediately
beneficial part of having pixel-sized windows.

And I wonder if it's really needed: Darren's complaint seems to point at
each redisplay being slow rather than redisplay happening too many times.


        Stefan

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

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Thu, 30 Jan 2014 23:39:07 +0800
> Cc: 16594@debbugs.gnu.org
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> 
> > I checked in a fix such that mouse dragging a line doesn't occur
> > pixelwise by default.  Does this improve the behavior?  I have no idea
> > how to interpret the profiler report - when you drag a line it will
> > always be the case that most of the cpu is consumed by that.
> 
> I tried the fix, the behavior is worse now.

Indeed.  Previously, I saw no sluggishness at all here (on
MS-Windows), now it is annoyingly apparent.

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

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Thu, 30 Jan 2014 16:01:42 +0800
> 
> emacs -q
> (scroll-bar-mode 'nil)
> C-x 3
> 
> then try to resize the windows using mouse several times and emacs
> redisplay is so slow that you can notice the fringes besides the drag
> handle is repainted from top to bottom frame by frame.
> 
> profiling shows `read-event' takes much of the time, is this the real
> cause?
> 
> - command-execute                                                 207  98%
>  - call-interactively                                             207  98%
>   - mouse-drag-vertical-line                                      202  96%
>    - mouse-drag-line                                              202  96%
>     - eval                                                        202  96%
>      - track-mouse                                                202  96%
>       - funcall                                                   202  96%
>        - #<compiled 0x40a712ed>                                   202  96%
>         - read-event                                              184  87%
>          - redisplay_internal (C function)                          1   0%
>             eval                                                    1   0%
>   + profiler-report                                                 5   2%
> - ...                                                               2   0%
>    Automatic GC                                                     2   0%
> + redisplay_internal (C function)                                   1   0%

According to the profile, if there is something slow, it's not in the
display engine, but in read-event.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Jan 2014 10:44:21 -0500
> Cc: 16594@debbugs.gnu.org, Darren Hoo <darren.hoo@gmail.com>
> 
> Darren's complaint seems to point at each redisplay being slow
> rather than redisplay happening too many times.

I see nothing in the original report that would suggest that redisplay
is slow.  Quite the contrary, it takes a minuscule fraction of the
total time.

Anyway, the "fix" actually makes things worse, so I think you can have
your wish back soon enough.

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

[Darren Hoo]

Hi,

I've met this symptom log time ago, I think long before you introduced
pixelwise feature.

I can not reproduce it with Gtk+, maybe it's an NS specific problem.
I wonder if Jan can take some time to look at it(Bug#16594).

martin rudalics <rudalics@gmx.at> writes:

>
> I checked in a fix such that mouse dragging a line doesn't occur
> pixelwise by default.  Does this improve the behavior?  I have no idea
> how to interpret the profiler report - when you drag a line it will
> always be the case that most of the cpu is consumed by that.
>

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

[martin rudalics]

> Anyway, the "fix" actually makes things worse, so I think you can have
> your wish back soon enough.

I tried to uncommit it with

bzr uncommit

but apparently this doesn't work.  I don't get a response :-(

martin

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

[martin rudalics]

> I tried to uncommit it with
> 
> bzr uncommit
> 
> but apparently this doesn't work.  I don't get a response :-(

Any suggestions how to proceed?  Can it do any harm if I
kill the bzr process?

martin

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

[Eli Zaretskii]

> Date: Thu, 30 Jan 2014 18:27:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16594@debbugs.gnu.org, darren.hoo@gmail.com
> 
> > I tried to uncommit it with
> > 
> > bzr uncommit
> > 
> > but apparently this doesn't work.  I don't get a response :-(

You cannot uncommit, because Savannah doesn't allow that.

> Any suggestions how to proceed?  Can it do any harm if I
> kill the bzr process?

No, but afterwards you need to "bzr break-lock".

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

[martin rudalics]

> No, but afterwards you need to "bzr break-lock".

OK.  But when I do

bzr break-lock c:/emacs/trunk/

nothing happens.

martin (thanks for the revert)

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

[Eli Zaretskii]

> Date: Thu, 30 Jan 2014 18:57:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16594@debbugs.gnu.org, darren.hoo@gmail.com
> 
> > No, but afterwards you need to "bzr break-lock".
> 
> OK.  But when I do
> 
> bzr break-lock c:/emacs/trunk/
> 
> nothing happens.

That means there was no lock to break.

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

[martin rudalics]

 > That's sad.  I thought it was one of the nicest and most immediately
 > beneficial part of having pixel-sized windows.

Strictly spoken it was a bug - the pre-pixelwise behavior should have
been preserved and that was to resize line/characterwise.  What if
someone insists that her windows should always have an integral multiple
of the character size?  The idea was to make pixelwise effects
obtainable only via setting `window-resize-pixelwise' to non-nil.

 > And I wonder if it's really needed: Darren's complaint seems to point at
 > each redisplay being slow rather than redisplay happening too many times.

The resizing behavior is sluggish indeed - especially on Lucid and
Motif.  Try with the upper window in a vertical split and

(while t
   (adjust-window-trailing-edge nil 1 nil 1)
   (sit-for 0.1))

martin

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

[Darren Hoo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> 
>> Darren's complaint seems to point at each redisplay being slow
>> rather than redisplay happening too many times.
>
> I see nothing in the original report that would suggest that redisplay
> is slow.  Quite the contrary, it takes a minuscule fraction of the
> total time.

In case I have not described my problem precise enough, maybe this
screencast I take will clear things up a bit:

http://blog.glib.cc/resize.html

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

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  16594@debbugs.gnu.org
> Date: Fri, 31 Jan 2014 02:57:58 +0800
> 
> In case I have not described my problem precise enough, maybe this
> screencast I take will clear things up a bit:
> 
> http://blog.glib.cc/resize.html

I see nothing of the kind on my system.  Moreover, what you show
doesn't look like an Emacs redisplay problem, but rather like some
low-level redraw problem.

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

[Stefan Monnier]

> of the character size?  The idea was to make pixelwise effects
> obtainable only via setting `window-resize-pixelwise' to non-nil.

I see it now.  I just had assumed that window-resize-pixelwise was
already t by default (this assumption was based on the behavior while
dragging windows ;-).

I think the default for that should be t.  But we can delay this change
to post-24.4.


        Stefan

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

[Darren Hoo]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Darren Hoo <darren.hoo@gmail.com>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  16594@debbugs.gnu.org
>> Date: Fri, 31 Jan 2014 02:57:58 +0800
>> 
>> In case I have not described my problem precise enough, maybe this
>> screencast I take will clear things up a bit:
>> 
>> http://blog.glib.cc/resize.html
>
> I see nothing of the kind on my system.  Moreover, what you show
> doesn't look like an Emacs redisplay problem, but rather like some
> low-level redraw problem.

indeed, it seems that this redisplay_internal is problematic:


[-- Attachment #2: redisplay_internal --]
[-- Type: image/png, Size: 497367 bytes --]

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

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: 16594@debbugs.gnu.org
> Date: Fri, 31 Jan 2014 11:16:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Darren Hoo <darren.hoo@gmail.com>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  16594@debbugs.gnu.org
> >> Date: Fri, 31 Jan 2014 02:57:58 +0800
> >> 
> >> In case I have not described my problem precise enough, maybe this
> >> screencast I take will clear things up a bit:
> >> 
> >> http://blog.glib.cc/resize.html
> >
> > I see nothing of the kind on my system.  Moreover, what you show
> > doesn't look like an Emacs redisplay problem, but rather like some
> > low-level redraw problem.
> 
> indeed, it seems that this redisplay_internal is problematic:

No, it's read-char and x_write_glyphs.  The latter calls the X server.

Of the total 345 ms, 130 ms are used by read-char and another 154 ms
by x_write_glyphs and x_clear_end_of_line, together these two take 284
ms, or 82% of the time.  The rest is distributed among the following
functions that are part of the display engine:

  redisplay_internal   18 ms
  update_window        36 ms
  update_window_line   14 ms

Given that dragging the divider involves redrawing every line in every
window, these times are entirely reasonable, and seem to confirm my
suspicions that the problem is on the X level.

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

[Jan D.]

Hi.

Eli Zaretskii skrev 2014-01-31 09:22:

> No, it's read-char and x_write_glyphs.  The latter calls the X server.

I got the impression he ran an NS build?  No X server involved.  Still 
platform specific though.

	Jan D.

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

[martin rudalics]

 > I see it now.  I just had assumed that window-resize-pixelwise was
 > already t by default (this assumption was based on the behavior while
 > dragging windows ;-).

Apart from frame maximizing, line dragging should be the only occasion
where pixelwise resizing leaks through by default.  I forgot to change
mouse.el appropriately, maybe so because it wasn't too trivial.

 > I think the default for that should be t.  But we can delay this change
 > to post-24.4.

OK.

martin

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

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 10:58:01 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: Darren Hoo <darren.hoo@gmail.com>, 16594@debbugs.gnu.org
> 
> Eli Zaretskii skrev 2014-01-31 09:22:
> 
> > No, it's read-char and x_write_glyphs.  The latter calls the X server.
> 
> I got the impression he ran an NS build?  No X server involved.

So what does x_write_glyphs etc. do in the NS build?

> Still platform specific though.

Right, or at least it seems so.

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

[Jan D.]

Eli Zaretskii skrev 2014-01-31 12:31:
>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Darren Hoo <darren.hoo@gmail.com>, 16594@debbugs.gnu.org
>>
>> Eli Zaretskii skrev 2014-01-31 09:22:
>>
>>> No, it's read-char and x_write_glyphs.  The latter calls the X server.
>>
>> I got the impression he ran an NS build?  No X server involved.
>
> So what does x_write_glyphs etc. do in the NS build?
>

The same as on all platforms, it is generic.
Basically calls draw_glyphs, which uses a couple of RIF functions.

	Jan D.

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

[Darren Hoo]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Darren Hoo <darren.hoo@gmail.com>, 16594@debbugs.gnu.org
>> 
>> Eli Zaretskii skrev 2014-01-31 09:22:
>> 
>> > No, it's read-char and x_write_glyphs.  The latter calls the X server.
>> 
>> I got the impression he ran an NS build?  No X server involved.
>
> So what does x_write_glyphs etc. do in the NS build?

Maybe inverted call tree shows it clearer:


[-- Attachment #2: argb32_image_mark_RGB32 --]
[-- Type: image/png, Size: 206280 bytes --]

[-- Attachment #3: Type: text/plain, Size: 121 bytes --]


Not sure whether it's related but someone says this:

http://lists.apple.com/archives/quartz-dev/2007/Nov/msg00113.html

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

[Jan D.]

Hello.

Darren Hoo skrev 2014-01-31 13:54:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>>> From: "Jan D." <jan.h.d@swipnet.se>
>>> CC: Darren Hoo <darren.hoo@gmail.com>, 16594@debbugs.gnu.org
>>>
>>> Eli Zaretskii skrev 2014-01-31 09:22:
>>>
>>>> No, it's read-char and x_write_glyphs.  The latter calls the X server.
>>>
>>> I got the impression he ran an NS build?  No X server involved.
>>
>> So what does x_write_glyphs etc. do in the NS build?
>
> Maybe inverted call tree shows it clearer:
>
>

This implies that turning of fringes should behave much better.  Can you 
try that?

	Jan D.

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

[Darren Hoo]

"Jan D." <jan.h.d@swipnet.se> writes:


> This implies that turning of fringes should behave much better.  Can
> you try that?
>

Not much perceptible improvement.

Using Graphic Tools for Xcode, I can see clearly the lines drawn one by
one when dragged. So it's not just drawing fringes is slow.

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

[Darren Hoo]

Paul, could you kindly take a look at this(Bug#16594)?

After some digging, I finally find out that this is regression
introduced by this commit:

 revno: 110152
 fixes bug: http://debbugs.gnu.org/12471
 committer: Paul Eggert <eggert@cs.ucla.edu>
 branch nick: trunk
 timestamp: Sun 2012-09-23 01:44:20 -0700
 message:
   Simplify and avoid signal-handling races.

not the immediate preceding one (seems to me much more probable)

 revno: 110151
 fixes bug: http://debbugs.gnu.org/12445
 committer: Jan D. <jan.h.d@swipnet.se>
 branch nick: trunk
 timestamp: Sun 2012-09-23 10:28:12 +0200
 message:
   * nsterm.m (ns_dumpglyphs_image): dr is a new rect to draw image into,
   background rect may be larger.


Yes, I double checked 110151 and it behaves well.

BTW I can only reproduce it on Mac OSX, so it maybe platform specific.

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

[Paul Eggert]

Darren Hoo wrote:

> BTW I can only reproduce it on Mac OSX, so it maybe platform specific.

Sorry, I don't use OS X.  I did build trunk bzr 110151 and 110152 on 
Fedora 20 x86-64, configured with "./configure CFLAGS='-g3 -O0' 
--with-x-toolkit=lucid", but I don't observe any difference in behavior.

A shot in the dark: what are the values of timer-list and 
timer-idle-list on OS X?

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

[Darren Hoo]

Paul Eggert <eggert@cs.ucla.edu> writes:

> A shot in the dark: what are the values of timer-list and
> timer-idle-list on OS X?

timer-list is nil

timer-idle-list is
([t 0 0 500000 0.5 blink-cursor-start nil idle 0]
 [t 0 0 500000 t jit-lock-context-fontify nil idle 0])

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

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 22:08:06 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: 16594@debbugs.gnu.org
> 
> Darren Hoo wrote:
> 
> > BTW I can only reproduce it on Mac OSX, so it maybe platform specific.
> 
> Sorry, I don't use OS X.  I did build trunk bzr 110151 and 110152 on 
> Fedora 20 x86-64, configured with "./configure CFLAGS='-g3 -O0' 
> --with-x-toolkit=lucid", but I don't observe any difference in behavior.

Could this be caused by the following hunk from r110152's changes?

  @@ -3352,17 +3352,7 @@ ns_read_socket (struct terminal *termina
     if ([NSApp modalWindow] != nil)
       return -1;

  -  if (interrupt_input_blocked)
  -    {
  -      interrupt_input_pending = 1;
  -      pending_signals = 1;
  -      return -1;
  -    }
  -
  -  interrupt_input_pending = 0;
  -  pending_signals = pending_atimers;
  -
  -  BLOCK_INPUT;
  +  block_input ();
     n_emacs_events_pending = 0;
     EVENT_INIT (ev);
     emacs_event = &ev;

This is NS-specific, so it won't cause any changes on Fedora.

The removal of the condition to return early seems to be a non-trivial
change, but I don't really understand the importance of this code.

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

[Paul Eggert]

Eli Zaretskii wrote:
> This is NS-specific

The same change was made to xterm.c's XTread_socket, so even if that 
particular hunk is NS-specific, the overall change applied to the X 
platform too.  I don't see why NS would react differently, though of 
course I could be missing something.

Continuing on my guess, which may well be a wild goose chase, can you 
use DTrace to see what system calls the offending Emacs is executing? 
I'm curious about how often timers are expiring during the misbehavior, 
and even if I'm wrong DTrace is often your friend for this sort of problem.

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

[Darren Hoo]

Paul Eggert <eggert@cs.ucla.edu> writes:

>
> Continuing on my guess, which may well be a wild goose chase, can you
> use DTrace to see what system calls the offending Emacs is executing?

I earlier used Xcode's instrument which I believe just interprets the
output from Dtrace/Dtruss. This argb32_image_mark_rgb32 low level call
is the top one which is in turn called by x_write_glyphs up on the call
tree. But as Eli has pointed out and I quote:

   Given that dragging the divider involves redrawing every line in
   every window, these times are entirely reasonable.

So it seems to me that this information I gave earlier is just misleading.

> I'm curious about how often timers are expiring during the
> misbehavior, and even if I'm wrong DTrace is often your friend for
> this sort of problem.

How can I get this timers expiring info by using Dtrace? A recipe to do
that is appreciated.

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

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  16594@debbugs.gnu.org
> Date: Sun, 02 Feb 2014 13:28:54 +0800
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> >
> > Continuing on my guess, which may well be a wild goose chase, can you
> > use DTrace to see what system calls the offending Emacs is executing?
> 
> I earlier used Xcode's instrument which I believe just interprets the
> output from Dtrace/Dtruss. This argb32_image_mark_rgb32 low level call
> is the top one which is in turn called by x_write_glyphs up on the call
> tree. But as Eli has pointed out and I quote:
> 
>    Given that dragging the divider involves redrawing every line in
>    every window, these times are entirely reasonable.

I was talking only about the times spent inside redisplay_internal,
update_window, and update_window_line.  The overall redrawing
behavior, as seen in the screencast, does not seem reasonable to me.

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

[Paul Eggert]

Darren Hoo wrote:
> How can I get this timers expiring info by using Dtrace? A recipe to do
> that is appreciated.

Sorry, I'm afraid you'll have to dig into this, as I don't use OS X and 
don't know the details of how to use DTrace with it.  Perhaps you can 
simply trace everything and then look for patterns in the trace.

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

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

While we're waiting for more info, attached is another shot in the dark; 
does this work around the problem?


[-- Attachment #2: atimer.diff --]
[-- Type: text/x-patch, Size: 593 bytes --]

=== modified file 'src/atimer.c'
--- src/atimer.c	2014-01-01 07:43:34 +0000
+++ src/atimer.c	2014-02-03 19:16:53 +0000
@@ -340,9 +340,12 @@
 static void
 run_timers (void)
 {
-  struct timespec now = current_timespec ();
+  struct timespec now = make_timespec (TYPE_MINIMUM (time_t), -1);
 
-  while (atimers && timespec_cmp (atimers->expiration, now) <= 0)
+  while (atimers
+	 && (timespec_cmp (atimers->expiration, now) <= 0
+	     || (now = current_timespec (),
+		 timespec_cmp (atimers->expiration, now) <= 0)))
     {
       struct atimer *t = atimers;
       atimers = atimers->next;

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

[Darren Hoo]

Paul Eggert <eggert@cs.ucla.edu> writes:

> While we're waiting for more info, attached is another shot in the
> dark; does this work around the problem?

Thanks, Paul

I've tried the patch but with no luck.

Whenever the hiccup occurs, it is always accompanied by two SIGALARMS
like this (Proccess... is the debugger output, others are my debug
outputs): 

Process 80842 stopped and restarted: thread 1 received signal: SIGALRM
timer called: timer 0x10073aef0!
Process 80842 stopped and restarted: thread 1 received signal: SIGALRM
timer called: timer 0x10073aef0!
redisplay time taken: 3.162885s

and here's the actual timer callback get called:

(lldb) p t
(atimer *) $0 = 0x000000010073aef0
(lldb) p *t
(atimer) $1 = {
  type = ATIMER_CONTINUOUS
  expiration = {
    tv_sec = 1391689620
    tv_nsec = 380898000
  }
  interval = {
    tv_sec = 2
    tv_nsec = 0
  }
  fn = 0x00000001000b4d90 (Emacs`poll_for_input at keyboard.c:1971)
  client_data = 0x0000000000000000
  next = 0x0000000000000000
}

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

[Darren Hoo]

>   fn = 0x00000001000b4d90 (Emacs`poll_for_input at keyboard.c:1971)

According to the documentation of poll-period:

  Polling is needed only when using X windows and SIGIO does not work.

if if SIGIO IS available do we still need POLL_FOR_INPUT for detecting
C-g on NS?

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

[Paul Eggert]

On 02/06/2014 07:23 AM, Darren Hoo wrote:
>> >   fn = 0x00000001000b4d90 (Emacs`poll_for_input at keyboard.c:1971)
> According to the documentation of poll-period:
>
>    Polling is needed only when using X windows and SIGIO does not work.
>
> if if SIGIO IS available do we still need POLL_FOR_INPUT for detecting
> C-g on NS?
>

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.

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

[Stefan Monnier]

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

Sounds like some old left-over.


        Stefan

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

[Darren Hoo]

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

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

[Paul Eggert]

Darren Hoo wrote:
> -  Fset_input_interrupt_mode (Qnil);
> +  Fset_input_interrupt_mode (Qt);

That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert 
in trunk bzr 94305.  The ChangeLog entry doesn't say why the change was 
made.  I'll CC: this to Adrian to see whether he can explain.  Adrian, 
the context for this email can be found at:

http://bugs.gnu.org/16594

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

[Darren Hoo]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Darren Hoo wrote:
>> -  Fset_input_interrupt_mode (Qnil);
>> +  Fset_input_interrupt_mode (Qt);
>
> That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert
> in trunk bzr 94305.  The ChangeLog entry doesn't say why the change
> was made.  I'll CC: this to Adrian to see whether he can explain.
> Adrian, the context for this email can be found at:
>
> http://bugs.gnu.org/16594

While waiting for Adrian, I noticed with this comibination:

  Fset_input_interrupt_mode (Qt);
  (custom-set-variables '(display-hourglass nil))

then after doing `M-! sleep 1000' I can no longer quit with
C-g but to wait the child process to finish itself.

I doubt SIGIO really works on Cocoa GUI mode, even
input-interrupt-mode is set to t, SIGIO may not be properly
initialized, more work needs to be done.

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

[Adrian Robert]

Hi,

We’re talking about half a decade ago here :) but I looked and thought I remembered it had something to do with Ctrl-G handling.  Fortunately there is some info on the mailing list here:

http://thread.gmane.org/gmane.emacs.devel/108069/focus=108328

The thread tells a bit about other parts of the code relating to the input loop integration affected by the change.  Some things might be different today, though I don’t think this area changes very fast..

-Adrian



On 2014.2.9, at 08:42, Darren Hoo <darren.hoo@gmail.com> wrote:

> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
>> Darren Hoo wrote:
>>> -  Fset_input_interrupt_mode (Qnil);
>>> +  Fset_input_interrupt_mode (Qt);
>> 
>> That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert
>> in trunk bzr 94305.  The ChangeLog entry doesn't say why the change
>> was made.  I'll CC: this to Adrian to see whether he can explain.
>> Adrian, the context for this email can be found at:
>> 
>> http://bugs.gnu.org/16594
> 
> While waiting for Adrian, I noticed with this comibination:
> 
>  Fset_input_interrupt_mode (Qt);
>  (custom-set-variables '(display-hourglass nil))
> 
> then after doing `M-! sleep 1000' I can no longer quit with
> C-g but to wait the child process to finish itself.
> 
> I doubt SIGIO really works on Cocoa GUI mode, even
> input-interrupt-mode is set to t, SIGIO may not be properly
> initialized, more work needs to be done.

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

[Adrian Robert]

> The thread tells a bit about other parts of the code relating to the input loop integration affected by the change.  Some things might be different today, though I don’t think this area changes very fast..


That said, after reading a bit more in the bug thread, the part "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” makes me think some things HAVE changed, since I know these problems were not present after the 2009-01-29 change.  So perhaps the whole timers and interrupts area should be revisited for NS.

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

[Stefan Monnier]

>> -  Fset_input_interrupt_mode (Qnil);
>> +  Fset_input_interrupt_mode (Qt);
> That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert in
> trunk bzr 94305.  The ChangeLog entry doesn't say why the change was made.
> I'll CC: this to Adrian to see whether he can explain.  Adrian, the context
> for this email can be found at:

I think Jan made changes in that area since then, so he may be able to
bring some light to this subject.

Jan?


        Stefan

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

[Jan Djärv]

Hi.

9 feb 2014 kl. 20:43 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>>> -  Fset_input_interrupt_mode (Qnil);
>>> +  Fset_input_interrupt_mode (Qt);
>> That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert in
>> trunk bzr 94305.  The ChangeLog entry doesn't say why the change was made.
>> I'll CC: this to Adrian to see whether he can explain.  Adrian, the context
>> for this email can be found at:
> 
> I think Jan made changes in that area since then, so he may be able to
> bring some light to this subject.
> 
> Jan?

The input loop is redone, but I haven't made changes in interrupt mode.
It may be that is works better now.

	Jan D.

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

[Jan Djärv]

Hello.

11 feb 2014 kl. 07:03 skrev Jan Djärv <jan.h.d@swipnet.se>:

> Hi.
> 
> 9 feb 2014 kl. 20:43 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
>>>> -  Fset_input_interrupt_mode (Qnil);
>>>> +  Fset_input_interrupt_mode (Qt);
>>> That reverses a change made 2009-01-29 10:36:22 +0000 by Adrian Robert in
>>> trunk bzr 94305.  The ChangeLog entry doesn't say why the change was made.
>>> I'll CC: this to Adrian to see whether he can explain.  Adrian, the context
>>> for this email can be found at:
>> 
>> I think Jan made changes in that area since then, so he may be able to
>> bring some light to this subject.
>> 
>> Jan?
> 
> The input loop is redone, but I haven't made changes in interrupt mode.
> It may be that is works better now.


I think the reason for polling on NS is that when doing things like
M-! sleep 1000

Emacs reads the output from the process in a loop.  This loop never allows the NS event loop to run, so C-g or any other key is not detected, thus it can't be interrupted.
I suspect it is similar for a lisp loop.

	Jan D.


	Jan D.