GNU bug report logs -
#16594
24.3.50; very slow redraw when resizing windows horizontally
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16594 in the body.
You can then email your comments to 16594 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 08:03:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Darren Hoo <darren.hoo <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 30 Jan 2014 08:03:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 13:48:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 15:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16594 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 15:45:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 16:15:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Darren Hoo <darren.hoo <at> gmail.com>
> Date: Thu, 30 Jan 2014 23:39:07 +0800
> Cc: 16594 <at> debbugs.gnu.org
>
> martin rudalics <rudalics <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 16:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Darren Hoo <darren.hoo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 16:28:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 30 Jan 2014 10:44:21 -0500
> Cc: 16594 <at> debbugs.gnu.org, Darren Hoo <darren.hoo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 16:40:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 16:54:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 17:28:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 17:34:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 30 Jan 2014 18:27:17 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16594 <at> debbugs.gnu.org, darren.hoo <at> 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".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 17:58:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 17:59:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 30 Jan 2014 18:57:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 16594 <at> debbugs.gnu.org, darren.hoo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 18:47:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 18:59:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Monnier <monnier <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 20:18:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Darren Hoo <darren.hoo <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 30 Jan 2014 21:58:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 03:19:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 16594 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Darren Hoo <darren.hoo <at> gmail.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16594 <at> 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:
[profile.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 08:23:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Darren Hoo <darren.hoo <at> gmail.com>
> Cc: 16594 <at> debbugs.gnu.org
> Date: Fri, 31 Jan 2014 11:16:47 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Darren Hoo <darren.hoo <at> gmail.com>
> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 09:59:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 10:43:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 11:32:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Jan 2014 10:58:01 +0100
> From: "Jan D." <jan.h.d <at> swipnet.se>
> CC: Darren Hoo <darren.hoo <at> gmail.com>, 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 12:15:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii skrev 2014-01-31 12:31:
>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>> From: "Jan D." <jan.h.d <at> swipnet.se>
>> CC: Darren Hoo <darren.hoo <at> gmail.com>, 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 12:56:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 16594 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>> From: "Jan D." <jan.h.d <at> swipnet.se>
>> CC: Darren Hoo <darren.hoo <at> gmail.com>, 16594 <at> 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:
[argb32_image_mark_rgb32.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
Not sure whether it's related but someone says this:
http://lists.apple.com/archives/quartz-dev/2007/Nov/msg00113.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 13:48:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Hello.
Darren Hoo skrev 2014-01-31 13:54:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Fri, 31 Jan 2014 10:58:01 +0100
>>> From: "Jan D." <jan.h.d <at> swipnet.se>
>>> CC: Darren Hoo <darren.hoo <at> gmail.com>, 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 13:59:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 16594 <at> debbugs.gnu.org (full text, mbox):
"Jan D." <jan.h.d <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Fri, 31 Jan 2014 20:58:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sat, 01 Feb 2014 06:09:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sat, 01 Feb 2014 09:13:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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])
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sat, 01 Feb 2014 17:47:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 31 Jan 2014 22:08:06 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 16594 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 02 Feb 2014 00:53:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 02 Feb 2014 05:30:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 02 Feb 2014 15:59:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> From: Darren Hoo <darren.hoo <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 16594 <at> debbugs.gnu.org
> Date: Sun, 02 Feb 2014 13:28:54 +0800
>
> Paul Eggert <eggert <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 02 Feb 2014 20:49:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Mon, 03 Feb 2014 19:28:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 16594 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
While we're waiting for more info, attached is another shot in the dark;
does this work around the problem?
[atimer.diff (text/x-patch, attachment)]
Added tag(s) moreinfo.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Tue, 04 Feb 2014 19:45:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 06 Feb 2014 13:08:02 GMT)
Full text and
rfc822 format available.
Message #112 received at submit <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 06 Feb 2014 15:24:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 06 Feb 2014 18:35:03 GMT)
Full text and
rfc822 format available.
Message #118 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Thu, 06 Feb 2014 22:16:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sat, 08 Feb 2014 22:44:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Feb 2014 04:18:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Feb 2014 06:43:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Feb 2014 07:10:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 16594 <at> debbugs.gnu.org (full text, mbox):
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 <at> gmail.com> wrote:
> Paul Eggert <eggert <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Feb 2014 07:17:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 16594 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Feb 2014 19:44:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 16594 <at> debbugs.gnu.org (full text, mbox):
>> - 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Tue, 11 Feb 2014 06:05:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Hi.
9 feb 2014 kl. 20:43 skrev Stefan Monnier <monnier <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Sun, 09 Mar 2014 13:29:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Hello.
11 feb 2014 kl. 07:03 skrev Jan Djärv <jan.h.d <at> swipnet.se>:
> Hi.
>
> 9 feb 2014 kl. 20:43 skrev Stefan Monnier <monnier <at> 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.
Forcibly Merged 16594 17124.
Request was from
Jan Djärv <jan.h.d <at> swipnet.se>
to
control <at> debbugs.gnu.org.
(Sat, 29 Mar 2014 12:21:03 GMT)
Full text and
rfc822 format available.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 26 Dec 2015 13:25:01 GMT)
Full text and
rfc822 format available.
Added tag(s) unreproducible.
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Fri, 12 Feb 2016 23:58:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#16594; Package
emacs.
(Wed, 09 Sep 2020 12:31:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 16594 <at> debbugs.gnu.org (full text, mbox):
Alan Third <alan <at> idiocy.org> writes:
> Looking through the complete bug thread it seems there was a good deal
> of discussion of this issue a couple of years ago, but it's unclear if
> there was any resolution.
It seems like this bug is unreproducible, and there's been a lot of
changes in this area, so it seems likely that the problem has gone
away -- in any case, it seems unlikely that we'll make further progress
in this bug report, so I'm closing it.
If this problem still persists, please respond to the debbugs address,
and we'll reopen.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
16594 <at> debbugs.gnu.org and Darren Hoo <darren.hoo <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 09 Sep 2020 12:31:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 08 Oct 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 209 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.