GNU bug report logs - #17124
24.3.50; Occasional Extremely Slow Redraws in OSX Emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17124 in the body.
You can then email your comments to 17124 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Froemling <ericfroemling <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Thu, 27 Mar 2014 14:23:28 -0700

Hello,
I've been using various OSX emacs builds from http://emacsformacosx.com
for a few years now.  I'm on a 2012 Retina Macbook Pro 15".  Every so
often when I am resizing the emacs frame or window I get a single
extremely slow redraw.  Here's a screen-capture video I was able to 
take of one just now as it was occurring:
http://www.files.froemling.net/misc/SlowEmacs.mov

I have not found a way to reliably reproduce these, though they happen
somewhat regularly when I am working.  Please let me know if there's
any other info I can provide or anything I can do on my end to help
get to the bottom of this.
Thanks much,
-Eric Froemling



In GNU Emacs 24.3.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
of 2014-03-03 on bob.porkrind.org
Repository revision: dmantipov <at> yandex.ru-20140303082758-a6p93v3jhm6yjy7k
Windowing system distributor `Apple', version 10.3.1265
Configured using:
`configure --host=x86_64-apple-darwin --build=i686-apple-darwin
--with-ns'

Important settings:
  locale-coding-system: utf-8-unix

Major mode: Grep

Minor modes in effect:
  shell-dirtrack-mode: t
  which-function-mode: t
  show-paren-mode: t
  recentf-mode: t
  global-hl-line-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-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:
C-n C-p C-p C-n C-n C-n C-n C-n C-n <down-mouse-1> 
<mouse-1> C-x C-f b s F l a <tab> g <tab> h <return> 
C-s r e n d e r e r : : C-e C-b C-b C-b C-b C-b C-b 
C-SPC C-e C-b M-w <M-return> M-< C-s f l a g n o d 
e : : C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p <return> <return> C-a C-y C-p C-n <tab> . m 
a r k U s e r M a n a g e d O b j e c t ( ) ; <return> 
C-p C-p <return> <tab> / / SPC t e l l SPC e m b e 
d d e d SPC o b j e c t s SPC n o t SPC t o SPC c o 
m p l i <backspace> a i n SPC a b o u t SPC y <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> w h e n SPC t h e y <return> <tab> / / 
SPC d i e SPC u n <backspace> <backspace> n o t SPC 
v i a SPC a SPC r e f e r e n c e . C-p C-e <M-backspace> 
<M-backspace> a b o u t SPC n o t SPC h a v i n g SPC 
r e f s C-n C-a C-k C-k C-x C-s C-n C-n C-p C-p C-p 
<help-echo> <down-mouse-1> <mouse-1> <help-echo> <help-echo> 
M-x r e p o r t SPC e m <tab> <return>

Recent messages:
Wrote /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp
Saving file /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp...
Wrote /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp
Making completion list...
Mark saved where search started
Mark set [2 times]
Mark saved where search started
Mark set
Saving file /Users/ericf/Documents/bombsquad/src/bsFlagNode.cpp...
Wrote /Users/ericf/Documents/bombsquad/src/bsFlagNode.cpp

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml 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 tex-mode latexenc kmacro
make-mode shell pcomplete misearch multi-isearch windmove add-log
which-func cc-langs cl cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs python help-mode imenu
cus-edit server saveplace paren recentf tree-widget wid-edit cl-loaddefs
cl-lib easymenu grep compile comint ansi-color ring hl-line delsel
cus-start cus-load 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)

Message #8 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 28 Mar 2014 10:20:22 +0300

> From: Eric Froemling <ericfroemling <at> gmail.com>
> Date: Thu, 27 Mar 2014 14:23:28 -0700
> 
> I've been using various OSX emacs builds from http://emacsformacosx.com
> for a few years now.  I'm on a 2012 Retina Macbook Pro 15".  Every so
> often when I am resizing the emacs frame or window I get a single
> extremely slow redraw.  Here's a screen-capture video I was able to 
> take of one just now as it was occurring:
> http://www.files.froemling.net/misc/SlowEmacs.mov

I cannot see that movie on my box.  Do you see delays between
characters on the same screen lines, or is the delay between screen
lines?

> I have not found a way to reliably reproduce these, though they happen
> somewhat regularly when I am working.  Please let me know if there's
> any other info I can provide or anything I can do on my end to help
> get to the bottom of this.

Try to look at the CPU load when this happens, in particular if more
than a single CPU core is busy (assuming you have a multi-core CPU).
If more than one core us busy, it probably means that more than one
thread is using the CPU (Emacs redisplay engine is single-threaded).

Message #11 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eric Froemling <ericfroemling <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 28 Mar 2014 09:19:41 -0700

[Message part 1 (text/plain, inline)]

Hi Eli,
Thanks for the info.
I’ll try to take a look at CPU load next time.
Here’s a youtube vid (unlisted) of my example in case that’s something
you can view:
https://www.youtube.com/watch?v=FSAGh4ER_AE&feature=youtu.be
I’m definitely seeing delays between characters on individual lines, but also
even things like drawing the borders around all of the frame’s windows are
taking multiple frames.  In total, refreshing the whole UI takes about
30 seconds whereas it is usually pretty instantaneous.  It looks sort of
like the slow-motion-redraw you see in X11 on a box that is completely
swapped out, (though there is definitely no swapping going on in this case)
-Eric

On Mar 28, 2014, at 12:20 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Eric Froemling <ericfroemling <at> gmail.com>
>> Date: Thu, 27 Mar 2014 14:23:28 -0700
>> 
>> I've been using various OSX emacs builds from http://emacsformacosx.com
>> for a few years now.  I'm on a 2012 Retina Macbook Pro 15".  Every so
>> often when I am resizing the emacs frame or window I get a single
>> extremely slow redraw.  Here's a screen-capture video I was able to 
>> take of one just now as it was occurring:
>> http://www.files.froemling.net/misc/SlowEmacs.mov
> 
> I cannot see that movie on my box.  Do you see delays between
> characters on the same screen lines, or is the delay between screen
> lines?
> 
>> I have not found a way to reliably reproduce these, though they happen
>> somewhat regularly when I am working.  Please let me know if there's
>> any other info I can provide or anything I can do on my end to help
>> get to the bottom of this.
> 
> Try to look at the CPU load when this happens, in particular if more
> than a single CPU core is busy (assuming you have a multi-core CPU).
> If more than one core us busy, it probably means that more than one
> thread is using the CPU (Emacs redisplay engine is single-threaded).

[Message part 2 (text/html, inline)]

Message #14 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 28 Mar 2014 20:43:39 +0300

> From: Eric Froemling <ericfroemling <at> gmail.com>
> Date: Fri, 28 Mar 2014 09:19:41 -0700
> Cc: 17124 <at> debbugs.gnu.org
> 
> I’ll try to take a look at CPU load next time.

Please do, it might give some clues.

> Here’s a youtube vid (unlisted) of my example in case that’s something
> you can view:
> https://www.youtube.com/watch?v=FSAGh4ER_AE&feature=youtu.be
> I’m definitely seeing delays between characters on individual lines, but also
> even things like drawing the borders around all of the frame’s windows are
> taking multiple frames.  In total, refreshing the whole UI takes about
> 30 seconds whereas it is usually pretty instantaneous.  It looks sort of
> like the slow-motion-redraw you see in X11 on a box that is completely
> swapped out, (though there is definitely no swapping going on in this case)

Looks like something is preempting the Emacs process all the time.

Message #17 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eric Froemling <ericfroemling <at> gmail.com>, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Sat, 29 Mar 2014 13:20:02 +0100

Hello.

This is most likely the same as 16594.

	Jan D.

2014-03-27 22:23, Eric Froemling skrev:
>
> Hello,
> I've been using various OSX emacs builds from http://emacsformacosx.com
> for a few years now.  I'm on a 2012 Retina Macbook Pro 15".  Every so
> often when I am resizing the emacs frame or window I get a single
> extremely slow redraw.  Here's a screen-capture video I was able to
> take of one just now as it was occurring:
> http://www.files.froemling.net/misc/SlowEmacs.mov
>
> I have not found a way to reliably reproduce these, though they happen
> somewhat regularly when I am working.  Please let me know if there's
> any other info I can provide or anything I can do on my end to help
> get to the bottom of this.
> Thanks much,
> -Eric Froemling
>
>
>
> In GNU Emacs 24.3.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
> of 2014-03-03 on bob.porkrind.org
> Repository revision: dmantipov <at> yandex.ru-20140303082758-a6p93v3jhm6yjy7k
> Windowing system distributor `Apple', version 10.3.1265
> Configured using:
> `configure --host=x86_64-apple-darwin --build=i686-apple-darwin
> --with-ns'
>
> Important settings:
>    locale-coding-system: utf-8-unix
>
> Major mode: Grep
>
> Minor modes in effect:
>    shell-dirtrack-mode: t
>    which-function-mode: t
>    show-paren-mode: t
>    recentf-mode: t
>    global-hl-line-mode: t
>    delete-selection-mode: t
>    tooltip-mode: t
>    electric-indent-mode: t
>    mouse-wheel-mode: t
>    menu-bar-mode: t
>    file-name-shadow-mode: t
>    global-font-lock-mode: t
>    font-lock-mode: t
>    blink-cursor-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:
> C-n C-p C-p C-n C-n C-n C-n C-n C-n <down-mouse-1>
> <mouse-1> C-x C-f b s F l a <tab> g <tab> h <return>
> C-s r e n d e r e r : : C-e C-b C-b C-b C-b C-b C-b
> C-SPC C-e C-b M-w <M-return> M-< C-s f l a g n o d
> e : : C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p
> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p
> C-p C-p <return> <return> C-a C-y C-p C-n <tab> . m
> a r k U s e r M a n a g e d O b j e c t ( ) ; <return>
> C-p C-p <return> <tab> / / SPC t e l l SPC e m b e
> d d e d SPC o b j e c t s SPC n o t SPC t o SPC c o
> m p l i <backspace> a i n SPC a b o u t SPC y <backspace>
> <backspace> <backspace> <backspace> <backspace> <backspace>
> <backspace> w h e n SPC t h e y <return> <tab> / /
> SPC d i e SPC u n <backspace> <backspace> n o t SPC
> v i a SPC a SPC r e f e r e n c e . C-p C-e <M-backspace>
> <M-backspace> a b o u t SPC n o t SPC h a v i n g SPC
> r e f s C-n C-a C-k C-k C-x C-s C-n C-n C-p C-p C-p
> <help-echo> <down-mouse-1> <mouse-1> <help-echo> <help-echo>
> M-x r e p o r t SPC e m <tab> <return>
>
> Recent messages:
> Wrote /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp
> Saving file /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp...
> Wrote /Users/ericf/Documents/bombsquad/src/bsSpazNode.cpp
> Making completion list...
> Mark saved where search started
> Mark set [2 times]
> Mark saved where search started
> Mark set
> Saving file /Users/ericf/Documents/bombsquad/src/bsFlagNode.cpp...
> Wrote /Users/ericf/Documents/bombsquad/src/bsFlagNode.cpp
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
> rfc822 mml 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 tex-mode latexenc kmacro
> make-mode shell pcomplete misearch multi-isearch windmove add-log
> which-func cc-langs cl cc-mode cc-fonts cc-guess cc-menus cc-cmds
> cc-styles cc-align cc-engine cc-vars cc-defs python help-mode imenu
> cus-edit server saveplace paren recentf tree-widget wid-edit cl-loaddefs
> cl-lib easymenu grep compile comint ansi-color ring hl-line delsel
> cus-start cus-load 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)
>
>

Message #22 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eric Froemling <ericfroemling <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Mon, 31 Mar 2014 22:23:33 -0700

[Message part 1 (text/plain, inline)]

Ok here’s some further info/possible repro case if it is of use:
I built my own emacs by doing a bzr branch bzr://bzr.sv.gnu.org/emacs/trunk,
then autogen.sh and ./configure —with-ns
I removed my .emacs file so as to get default settings, then launched emacs,
opened a large text file, and subdivided the frame into several windows.
With this setup it is quite easy for me to get the slowdown to happen by just
dragging a divider around for a bit.
Here’s a clip of a slowdown with the activity monitor visible:
https://www.youtube.com/watch?v=olkyqVOWSLs
You can see that emacs is only using a few percent cpu throughout the slow redraw,
whatever that may imply.
I’ve also attached a sample I took of emacs during such a slowdown.
It looks like a lot of calls are blocking in _CGSSynchronizeWindowBackingStore
under the hood.
Hope this is helpful.  Please let me know if I can provide more info.
Thanks
-Eric

[EmacsSample.txt (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

On Mar 28, 2014, at 10:43 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Eric Froemling <ericfroemling <at> gmail.com>
>> Date: Fri, 28 Mar 2014 09:19:41 -0700
>> Cc: 17124 <at> debbugs.gnu.org
>> 
>> I’ll try to take a look at CPU load next time.
> 
> Please do, it might give some clues.
> 
>> Here’s a youtube vid (unlisted) of my example in case that’s something
>> you can view:
>> https://www.youtube.com/watch?v=FSAGh4ER_AE&feature=youtu.be
>> I’m definitely seeing delays between characters on individual lines, but also
>> even things like drawing the borders around all of the frame’s windows are
>> taking multiple frames.  In total, refreshing the whole UI takes about
>> 30 seconds whereas it is usually pretty instantaneous.  It looks sort of
>> like the slow-motion-redraw you see in X11 on a box that is completely
>> swapped out, (though there is definitely no swapping going on in this case)
> 
> Looks like something is preempting the Emacs process all the time.

Message #25 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Tue, 01 Apr 2014 18:03:18 +0300

> From: Eric Froemling <ericfroemling <at> gmail.com>
> Date: Mon, 31 Mar 2014 22:23:33 -0700
> Cc: 17124 <at> debbugs.gnu.org
> 
> Ok here’s some further info/possible repro case if it is of use:
> I built my own emacs by doing a bzr branch bzr://bzr.sv.gnu.org/emacs/trunk,
> then autogen.sh and ./configure —with-ns
> I removed my .emacs file so as to get default settings, then launched emacs,
> opened a large text file, and subdivided the frame into several windows.
> With this setup it is quite easy for me to get the slowdown to happen by just
> dragging a divider around for a bit.
> Here’s a clip of a slowdown with the activity monitor visible:
> https://www.youtube.com/watch?v=olkyqVOWSLs
> You can see that emacs is only using a few percent cpu throughout the slow redraw,
> whatever that may imply.

If Emacs does not use too much CPU cycles, it's probably not an Emacs
problem.

> I’ve also attached a sample I took of emacs during such a slowdown.
> It looks like a lot of calls are blocking in _CGSSynchronizeWindowBackingStore
> under the hood.

I don't know how to read that.  Are the numbers there CPU times, or
are they numbers of calls to each function?  If the latter, then they
are not very useful in this case.

Thanks.

Message #28 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eric Froemling <ericfroemling <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Tue, 1 Apr 2014 09:57:03 -0700

On Apr 1, 2014, at 8:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Eric Froemling <ericfroemling <at> gmail.com>
>> Date: Mon, 31 Mar 2014 22:23:33 -0700
>> Cc: 17124 <at> debbugs.gnu.org
>> 
>> Ok here’s some further info/possible repro case if it is of use:
>> I built my own emacs by doing a bzr branch bzr://bzr.sv.gnu.org/emacs/trunk,
>> then autogen.sh and ./configure —with-ns
>> I removed my .emacs file so as to get default settings, then launched emacs,
>> opened a large text file, and subdivided the frame into several windows.
>> With this setup it is quite easy for me to get the slowdown to happen by just
>> dragging a divider around for a bit.
>> Here’s a clip of a slowdown with the activity monitor visible:
>> https://www.youtube.com/watch?v=olkyqVOWSLs
>> You can see that emacs is only using a few percent cpu throughout the slow redraw,
>> whatever that may imply.
> 
> If Emacs does not use too much CPU cycles, it's probably not an Emacs
> problem.

> 
>> I’ve also attached a sample I took of emacs during such a slowdown.
>> It looks like a lot of calls are blocking in _CGSSynchronizeWindowBackingStore
>> under the hood.
> 
> I don't know how to read that.  Are the numbers there CPU times, or
> are they numbers of calls to each function?  If the latter, then they
> are not very useful in this case.

You can see the total samples per thread broken up down into the call chain.
..so in the main thread the time seems to be somewhat evenly divided between
draw_glyphs, draw_window_fringes, etc, all of which seem to be blocking
in _CGSSynchronizeWindowBackingStore.

Can anyone try to repro this?  (basically open a large buffer, subdivide a
frame into quite a few windows, and then vigorously shake a horizontal
divider for a bit.  In my case I usually get a slow refresh after 5-15 seconds).
It can happen in other cases too such as window resizes but this seems
to be the easiest way to trigger it.
I’m using a pretty vanilla OSX Mavericks install on a retina MBP; curious
if others are seeing this..

> 
> Thanks.

Message #31 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 12:44:58 +0200

Hello.

1 apr 2014 kl. 18:57 skrev Eric Froemling <ericfroemling <at> gmail.com>:

> 
> On Apr 1, 2014, at 8:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>>> From: Eric Froemling <ericfroemling <at> gmail.com>
>>> Date: Mon, 31 Mar 2014 22:23:33 -0700
>>> Cc: 17124 <at> debbugs.gnu.org
>>> 
>>> Ok here’s some further info/possible repro case if it is of use:
>>> I built my own emacs by doing a bzr branch bzr://bzr.sv.gnu.org/emacs/trunk,
>>> then autogen.sh and ./configure —with-ns
>>> I removed my .emacs file so as to get default settings, then launched emacs,
>>> opened a large text file, and subdivided the frame into several windows.
>>> With this setup it is quite easy for me to get the slowdown to happen by just
>>> dragging a divider around for a bit.
>>> Here’s a clip of a slowdown with the activity monitor visible:
>>> https://www.youtube.com/watch?v=olkyqVOWSLs
>>> You can see that emacs is only using a few percent cpu throughout the slow redraw,
>>> whatever that may imply.
>> 
>> If Emacs does not use too much CPU cycles, it's probably not an Emacs
>> problem.
> 

It actually is.  Emacs draws too much, and the backing store gets swamped with requests.
See https://developer.apple.com/library/mac/documentation/Performance/Conceptual/Drawing/Articles/FlushingContent.html
and
https://developer.apple.com/library/mac/technotes/tn2133/_index.html

With the "shake the divider" recepie (see below), redisplay_internal is called more than 30 times per second.  On an old computer (end of 2008) I get about 37 times per second.
But each redisplay results in multiple draw_begin/end, so for drawing, it is more than 37 times per second.

What we would need is for redisplay to be more in line with what toolkits does w.r.t. drawing.
First calculate all glyphs, but don't do any drawing.
Then invalidate those regions that needs redraw (a new RIF function), and let the backends deside when it is appropriate to draw by calling a redisplay function that does the actual drawing, based on the latest glyphs.  This was suggested here:

http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg00821.html

with some further discussion about here:

http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00433.html

I think there is room for optimizations in the generic display also, for example moving the mouse redraws the entire mode line, even if the mouse pointer is outside the frame.

>> 
>>> I’ve also attached a sample I took of emacs during such a slowdown.
>>> It looks like a lot of calls are blocking in _CGSSynchronizeWindowBackingStore
>>> under the hood.
>> 
>> I don't know how to read that.  Are the numbers there CPU times, or
>> are they numbers of calls to each function?  If the latter, then they
>> are not very useful in this case.
> 
> You can see the total samples per thread broken up down into the call chain.
> ..so in the main thread the time seems to be somewhat evenly divided between
> draw_glyphs, draw_window_fringes, etc, all of which seem to be blocking
> in _CGSSynchronizeWindowBackingStore.
> 
> Can anyone try to repro this?  (basically open a large buffer, subdivide a
> frame into quite a few windows, and then vigorously shake a horizontal
> divider for a bit.  In my case I usually get a slow refresh after 5-15 seconds).
> It can happen in other cases too such as window resizes but this seems
> to be the easiest way to trigger it.
> I’m using a pretty vanilla OSX Mavericks install on a retina MBP; curious
> if others are seeing this..
> 

It is easy to trigger by shaking the divider.
I can sort of fix this by replacing some flushWindow with setNeedsDisplay:YES.
This has the drawback that updating the frame while shaking the divider becomes slower, and sometimes stops updating the frame at all until I stop moving the mouse.

	Jan D.

Message #34 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: ericfroemling <at> gmail.com, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 16:37:50 +0300

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Fri, 27 Jun 2014 12:44:58 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  17124 <at> debbugs.gnu.org
> 
> With the "shake the divider" recepie (see below), redisplay_internal is called more than 30 times per second.  On an old computer (end of 2008) I get about 37 times per second.
> But each redisplay results in multiple draw_begin/end, so for drawing, it is more than 37 times per second.

Does it help to set redisplay-dont-pause to nil?

> What we would need is for redisplay to be more in line with what toolkits does w.r.t. drawing.
> First calculate all glyphs, but don't do any drawing.
> Then invalidate those regions that needs redraw (a new RIF function), and let the backends deside when it is appropriate to draw by calling a redisplay function that does the actual drawing, based on the latest glyphs.

We already have the first stage of that in place: that's
redisplay_windows, which is called for each frame that needs to be
redisplayed.  What you are suggesting is to make update_frame, which
currently redraws the frame's windows based on what redisplay_windows
calculated, to instead just mark the areas which need redrawing as
dirty.

That sounds easy enough, but the problem is that we might need more
display updates until the backend decides that it is a good time to
actually redraw.  E.g., the user might type some commands in the
meantime.  AFAIU, what you are saying is let all these changes affect
only the glyph matrices that redisplay_windows calculates, so that
when the backend wants to redraw, the Emacs function that actually
redraws will see the up-to-date glyph matrices and use them.

This could work if the backend can accumulate durty regions
incrementally.  IOW, if it gets 2 requests for areas that partially
overlap, will it mark the union of those areas as dirty?  If not, we
will need serious changes to how redisplay_windows and its subroutines
work, because they currently assume the previous full redisplay cycle
updated everything on the glass, and don't keep record of the glyph
matrices beyond the last redisplay.

Incidentally, I don't think your suggestion will help in the "shake
the divider" scenario: when window dimensions are changed, we toss the
glyph matrices of the affected windows, and then allocate them anew
(and perform a thorough redisplay of those windows).  So this will
anyhow require to redisplay the entire window completely, and the
backend will not be able to save us any redraws.

> I think there is room for optimizations in the generic display also, for example moving the mouse redraws the entire mode line, even if the mouse pointer is outside the frame.

Please show the recipe to reproduce this.  I just tried a naive way of
doing that, and didn't see any mode-line updates even when the mouse
is inside the frame.  So I must be missing something.

> I can sort of fix this by replacing some flushWindow with setNeedsDisplay:YES.
> This has the drawback that updating the frame while shaking the divider becomes slower, and sometimes stops updating the frame at all until I stop moving the mouse.

Isn't this a problem that might make the entire idea unworkable?

Message #37 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ericfroemling <at> gmail.com, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 19:13:00 +0200

Hello.

27 jun 2014 kl. 15:37 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Fri, 27 Jun 2014 12:44:58 +0200
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> 17124 <at> debbugs.gnu.org
>> 
>> With the "shake the divider" recepie (see below), redisplay_internal is called more than 30 times per second.  On an old computer (end of 2008) I get about 37 times per second.
>> But each redisplay results in multiple draw_begin/end, so for drawing, it is more than 37 times per second.
> 
> Does it help to set redisplay-dont-pause to nil?

The "shake the divider" case becomes much worse, lots of flickering and incomplete text.
Wheter it prevents the slow redraws in real usage is hard to tell.  It is not easily reproduced in normal Emacs usage.

> 
>> What we would need is for redisplay to be more in line with what toolkits does w.r.t. drawing.
>> First calculate all glyphs, but don't do any drawing.
>> Then invalidate those regions that needs redraw (a new RIF function), and let the backends deside when it is appropriate to draw by calling a redisplay function that does the actual drawing, based on the latest glyphs.
> 
> We already have the first stage of that in place: that's
> redisplay_windows, which is called for each frame that needs to be
> redisplayed.  What you are suggesting is to make update_frame, which
> currently redraws the frame's windows based on what redisplay_windows
> calculated, to instead just mark the areas which need redrawing as
> dirty.

Basically yes.

> 
> That sounds easy enough, but the problem is that we might need more
> display updates until the backend decides that it is a good time to
> actually redraw.  E.g., the user might type some commands in the
> meantime.  AFAIU, what you are saying is let all these changes affect
> only the glyph matrices that redisplay_windows calculates, so that
> when the backend wants to redraw, the Emacs function that actually
> redraws will see the up-to-date glyph matrices and use them.

Yes.

> 
> This could work if the backend can accumulate durty regions
> incrementally.  IOW, if it gets 2 requests for areas that partially
> overlap, will it mark the union of those areas as dirty?  If not, we
> will need serious changes to how redisplay_windows and its subroutines
> work, because they currently assume the previous full redisplay cycle
> updated everything on the glass, and don't keep record of the glyph
> matrices beyond the last redisplay.

The toolkits I know of can handle invalidating different regions.

> Incidentally, I don't think your suggestion will help in the "shake
> the divider" scenario: when window dimensions are changed, we toss the
> glyph matrices of the affected windows, and then allocate them anew
> (and perform a thorough redisplay of those windows).  So this will
> anyhow require to redisplay the entire window completely, and the
> backend will not be able to save us any redraws.

Not by itself, but if the backend is responsible for when actual drawing happens we can make sure we don't draw faster than the screen can update.  If the user is shaking the divider faster than we can draw, we should toss intermediate steps.  That is, if redisplay has to recalculate all matrices before they have been drawn on the screen, so be it.

In this case I suspect it does help.  When redisplay says "this region needs to redraw", the backend (NS) tells Cocoa, "this region needs to redraw".  Cocoa then calls our code to say "please redraw this region".  I assume Cocoa does not call our draw function faster than it can handle, i.e. it is called when the previous drawing is on screen.

I don't know if Cocoa actually does this, it is pure speculation.

> 
>> I think there is room for optimizations in the generic display also, for example moving the mouse redraws the entire mode line, even if the mouse pointer is outside the frame.
> 
> Please show the recipe to reproduce this.  I just tried a naive way of
> doing that, and didn't see any mode-line updates even when the mouse
> is inside the frame.  So I must be missing something.
> 

I had problems seeing what was drawn and when so I added debug code to see what the font driver actually draws.  But I see now that it is different for X11.  So it might be NS specific.  What can make the modeline redraw in one version of Emacs and not in another?  I thought all that was generic code.

>> I can sort of fix this by replacing some flushWindow with setNeedsDisplay:YES.
>> This has the drawback that updating the frame while shaking the divider becomes slower, and sometimes stops updating the frame at all until I stop moving the mouse.
> 
> Isn't this a problem that might make the entire idea unworkable?

Well, shake the divider is not really something normal a user does.  It is just a way to force the issue.  But slow redraws happens in normal usage also, i.e. switching buffers and editing.  It solves the second case, but makes shake the divider worse in terms of smooth redraws.

	Jan D.

Message #40 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eric Froemling <ericfroemling <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 10:30:04 -0700

[Message part 1 (text/plain, inline)]

I generally run into the slowdown maybe once every half-hour during real-world usage; a common trigger seems to be mouse clicks, drags, or scrolls, though I haven’t been able to pin down any predictable repro. cases aside from the shake-the-divider one.

As a janky workaround, I’ve found that switching to a different desktop and back during a slow redraw allows all the buffered draws to go through instantly; not sure if that implies anything useful.

-Eric

On Jun 27, 2014, at 10:13 AM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> The "shake the divider" case becomes much worse, lots of flickering and incomplete text.
> Wheter it prevents the slow redraws in real usage is hard to tell.  It is not easily reproduced in normal Emacs usage.

[Message part 2 (text/html, inline)]

Message #43 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: ericfroemling <at> gmail.com, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 22:57:23 +0300

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Fri, 27 Jun 2014 19:13:00 +0200
> Cc: ericfroemling <at> gmail.com,
>  17124 <at> debbugs.gnu.org
> 
> >> With the "shake the divider" recepie (see below), redisplay_internal is called more than 30 times per second.  On an old computer (end of 2008) I get about 37 times per second.
> >> But each redisplay results in multiple draw_begin/end, so for drawing, it is more than 37 times per second.
> > 
> > Does it help to set redisplay-dont-pause to nil?
> 
> The "shake the divider" case becomes much worse, lots of flickering and incomplete text.

But do you see less drawing requests sent to the backend?

> > Incidentally, I don't think your suggestion will help in the "shake
> > the divider" scenario: when window dimensions are changed, we toss the
> > glyph matrices of the affected windows, and then allocate them anew
> > (and perform a thorough redisplay of those windows).  So this will
> > anyhow require to redisplay the entire window completely, and the
> > backend will not be able to save us any redraws.
> 
> Not by itself, but if the backend is responsible for when actual drawing happens we can make sure we don't draw faster than the screen can update.

I actually find it hard to believe that we overwhelm the backend,
except, maybe, when the X client is on a remote machine.  E.g., on
Windows the "shake the divider" recipe doesn't show any signs of a
problem, and the CPU load is never more than a single execution unit
being busy, which means not much is at work except Emacs itself.  With
today's multi-core fast machines, how come it's impossible to redraw a
region 37 times a second?

> >> I think there is room for optimizations in the generic display also, for example moving the mouse redraws the entire mode line, even if the mouse pointer is outside the frame.
> > 
> > Please show the recipe to reproduce this.  I just tried a naive way of
> > doing that, and didn't see any mode-line updates even when the mouse
> > is inside the frame.  So I must be missing something.
> > 
> 
> I had problems seeing what was drawn and when so I added debug code to see what the font driver actually draws.  But I see now that it is different for X11.  So it might be NS specific.  What can make the modeline redraw in one version of Emacs and not in another?  I thought all that was generic code.

It _is_ generic code.  Perhaps we are not talking about the same
things: when you say that the mode line is redrawn, what exactly do
you see?

> Well, shake the divider is not really something normal a user does.  It is just a way to force the issue.  But slow redraws happens in normal usage also, i.e. switching buffers and editing.  It solves the second case, but makes shake the divider worse in terms of smooth redraws.

We need to compare the performance with this proposed feature with the
current implementation.  I think it's hard to talk about this without
some measurements, and probably also some reasonably important use
cases (which "shake the divider" isn't, IMO).

Message #46 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Froemling <ericfroemling <at> gmail.com>
Cc: jan.h.d <at> swipnet.se, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 27 Jun 2014 22:58:46 +0300

> From: Eric Froemling <ericfroemling <at> gmail.com>
> Date: Fri, 27 Jun 2014 10:30:04 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  17124 <at> debbugs.gnu.org
> 
> I generally run into the slowdown maybe once every half-hour during real-world usage; a common trigger seems to be mouse clicks, drags, or scrolls, though I haven’t been able to pin down any predictable repro. cases aside from the shake-the-divider one.
> 
> As a janky workaround, I’ve found that switching to a different desktop and back during a slow redraw allows all the buffered draws to go through instantly; not sure if that implies anything useful.

I know almost nothing about this stuff, but it surely smells like some
issue with the backend, not with Emacs.

Message #49 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ericfroemling <at> gmail.com, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Mon, 30 Jun 2014 14:55:22 +0200

27 jun 2014 kl. 21:57 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Fri, 27 Jun 2014 19:13:00 +0200
>> Cc: ericfroemling <at> gmail.com,
>> 17124 <at> debbugs.gnu.org
>> 
>>>> With the "shake the divider" recepie (see below), redisplay_internal is called more than 30 times per second.  On an old computer (end of 2008) I get about 37 times per second.
>>>> But each redisplay results in multiple draw_begin/end, so for drawing, it is more than 37 times per second.
>>> 
>>> Does it help to set redisplay-dont-pause to nil?
>> 
>> The "shake the divider" case becomes much worse, lots of flickering and incomplete text.
> 
> But do you see less drawing requests sent to the backend?

No.

> 
>>> Incidentally, I don't think your suggestion will help in the "shake
>>> the divider" scenario: when window dimensions are changed, we toss the
>>> glyph matrices of the affected windows, and then allocate them anew
>>> (and perform a thorough redisplay of those windows).  So this will
>>> anyhow require to redisplay the entire window completely, and the
>>> backend will not be able to save us any redraws.
>> 
>> Not by itself, but if the backend is responsible for when actual drawing happens we can make sure we don't draw faster than the screen can update.
> 
> I actually find it hard to believe that we overwhelm the backend,
> except, maybe, when the X client is on a remote machine.  E.g., on
> Windows the "shake the divider" recipe doesn't show any signs of a
> problem, and the CPU load is never more than a single execution unit
> being busy, which means not much is at work except Emacs itself.  With
> today's multi-core fast machines, how come it's impossible to redraw a
> region 37 times a second?

Well, the actual number is more than 37.  37 is the number of times redisplay is called.
But within one redisplay, there is a couple of separate update_begin/end blocks.

There was a couple of extra redraws happening in the NS port, but after removing them, I can still see problems with shake the divider.

It all goes away if drawing is done the normal way, i.e. from the event handler.
Maybe OSX is optimized for that case, as it covers about every application except Emacs.
The Emacs way is really only ment for small updates outside the event loop.

> 
>>>> I think there is room for optimizations in the generic display also, for example moving the mouse redraws the entire mode line, even if the mouse pointer is outside the frame.
>>> 
>>> Please show the recipe to reproduce this.  I just tried a naive way of
>>> doing that, and didn't see any mode-line updates even when the mouse
>>> is inside the frame.  So I must be missing something.
>>> 
>> 
>> I had problems seeing what was drawn and when so I added debug code to see what the font driver actually draws.  But I see now that it is different for X11.  So it might be NS specific.  What can make the modeline redraw in one version of Emacs and not in another?  I thought all that was generic code.
> 
> It _is_ generic code.  Perhaps we are not talking about the same
> things: when you say that the mode line is redrawn, what exactly do
> you see?

I see the mode line redrawn by inspecting what strings are sent to the font backend.  Actually the whole buffer is redrawn, I was just looking at an empty buffer.  But these are the extra redrawn I mentioned above, they are gone in trunk now.

> 
>> Well, shake the divider is not really something normal a user does.  It is just a way to force the issue.  But slow redraws happens in normal usage also, i.e. switching buffers and editing.  It solves the second case, but makes shake the divider worse in terms of smooth redraws.
> 
> We need to compare the performance with this proposed feature with the
> current implementation.  I think it's hard to talk about this without
> some measurements, and probably also some reasonably important use
> cases (which "shake the divider" isn't, IMO).

With the extra redrawns gone, shake the divider performes rather well now if I force draws to the event loop.  There is the occational pause in redraw, but I guess that is expected.
But I can't do this all in the backend, the downside is that there are double redraws.  One for the redisplay call and one from the event loop when the redisplay is done.  Also, the event loop redraw redraws the whole frame.

If I get some time I'll try to make a test.

	Jan D.

Message #52 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: ericfroemling <at> gmail.com, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Mon, 30 Jun 2014 17:45:35 +0300

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Mon, 30 Jun 2014 14:55:22 +0200
> Cc: ericfroemling <at> gmail.com,
>  17124 <at> debbugs.gnu.org
> 
> >>> Does it help to set redisplay-dont-pause to nil?
> >> 
> >> The "shake the divider" case becomes much worse, lots of flickering and incomplete text.
> > 
> > But do you see less drawing requests sent to the backend?
> 
> No.

Strange.  When this variable is nil, redisplay should abandon its job
when it sees that some input is pending.

> > I actually find it hard to believe that we overwhelm the backend,
> > except, maybe, when the X client is on a remote machine.  E.g., on
> > Windows the "shake the divider" recipe doesn't show any signs of a
> > problem, and the CPU load is never more than a single execution unit
> > being busy, which means not much is at work except Emacs itself.  With
> > today's multi-core fast machines, how come it's impossible to redraw a
> > region 37 times a second?
> 
> Well, the actual number is more than 37.  37 is the number of times redisplay is called.
> But within one redisplay, there is a couple of separate update_begin/end blocks.

I'd expect one such block for every window that is affected by the
divider move.  If you see more, there's something else at work here.

> The Emacs way is really only ment for small updates outside the event loop.

Most of the updates are indeed small.

> >> I had problems seeing what was drawn and when so I added debug code to see what the font driver actually draws.  But I see now that it is different for X11.  So it might be NS specific.  What can make the modeline redraw in one version of Emacs and not in another?  I thought all that was generic code.
> > 
> > It _is_ generic code.  Perhaps we are not talking about the same
> > things: when you say that the mode line is redrawn, what exactly do
> > you see?
> 
> I see the mode line redrawn by inspecting what strings are sent to the font backend.  Actually the whole buffer is redrawn, I was just looking at an empty buffer.  But these are the extra redrawn I mentioned above, they are gone in trunk now.

So the redraws of the mode line when mouse is moved no longer happen
on the trunk?  If so, this is a good improvement.

> With the extra redrawns gone, shake the divider performes rather well now if I force draws to the event loop.  There is the occational pause in redraw, but I guess that is expected.
> But I can't do this all in the backend, the downside is that there are double redraws.  One for the redisplay call and one from the event loop when the redisplay is done.  Also, the event loop redraw redraws the whole frame.
> 
> If I get some time I'll try to make a test.

Thanks.

Message #55 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Bill Sacks <sacks <at> ucar.edu>
To: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Tue, 27 Jan 2015 13:09:18 -0700

For what it's worth: I experience problems similar to those noted in bug #17124. I am using Aquamacs on a Mac. In my case, though, the slow redraws occur when I am scrolling with the scroll wheel on my mouse.

Thank you,
Bill

Message #60 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bulldozer <kentdozier <at> gmail.com>
To: Bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Wed, 10 Feb 2016 12:25:54 -0700 (MST)

Over a year later, I am also still experiencing the slow redraw, usually when
using the mouse wheel to scroll. I can see it slowly going down each line,
one split window at a time, redrawing the text. Aquamacs is unresponsive
until it finishes redrawing all visible text.  

O/S: Mac OSX 10.9.5
Aquamacs 3.2 GNU Emacs 24.4.51.2
x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14



--
View this message in context: http://emacs.1067599.n5.nabble.com/bug-17124-24-3-50-Occasional-Extremely-Slow-Redraws-in-OSX-Emacs-tp318492p387399.html
Sent from the Emacs - Bugs mailing list archive at Nabble.com.

Message #63 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: bulldozer <kentdozier <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Wed, 10 Feb 2016 23:29:54 +0000

bulldozer <kentdozier <at> gmail.com> writes:

> Over a year later, I am also still experiencing the slow redraw, usually when
> using the mouse wheel to scroll. I can see it slowly going down each line,
> one split window at a time, redrawing the text. Aquamacs is unresponsive
> until it finishes redrawing all visible text.  
>
> O/S: Mac OSX 10.9.5
> Aquamacs 3.2 GNU Emacs 24.4.51.2
> x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14

Hi! I can't replicate this in Emacs 25. Would it be possible for you to
test it with Emacs 25 and see if you still get this problem?

I'm not using Aquamacs, but I notice they have a preview of 25 available.
-- 
Alan Third

Message #66 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bulldozer <kentdozier <at> gmail.com>
To: Bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Wed, 10 Feb 2016 17:26:47 -0700 (MST)

[Message part 1 (text/plain, inline)]

Sure, I just downloaded the latest nightly with Emacs 25.0.50.5.  I'll use
this for a while and report back.

On Wed, Feb 10, 2016 at 3:31 PM, Alan Third [via Emacs] <
ml-node+s1067599n387419h59 <at> n5.nabble.com> wrote:

> bulldozer <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=387419&i=0>> writes:
>
> > Over a year later, I am also still experiencing the slow redraw, usually
> when
> > using the mouse wheel to scroll. I can see it slowly going down each
> line,
> > one split window at a time, redrawing the text. Aquamacs is unresponsive
> > until it finishes redrawing all visible text.
> >
> > O/S: Mac OSX 10.9.5
> > Aquamacs 3.2 GNU Emacs 24.4.51.2
> > x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14
>
> Hi! I can't replicate this in Emacs 25. Would it be possible for you to
> test it with Emacs 25 and see if you still get this problem?
>
> I'm not using Aquamacs, but I notice they have a preview of 25 available.
> --
> Alan Third
>
>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://emacs.1067599.n5.nabble.com/bug-17124-24-3-50-Occasional-Extremely-Slow-Redraws-in-OSX-Emacs-tp318492p387419.html
> To unsubscribe from bug#17124: 24.3.50; Occasional Extremely Slow Redraws
> in OSX Emacs, click here
> <http://emacs.1067599.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=318492&code=a2VudGRvemllckBnbWFpbC5jb218MzE4NDkyfDkzMzc5MjgzNg==>
> .
> NAML
> <http://emacs.1067599.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://emacs.1067599.n5.nabble.com/bug-17124-24-3-50-Occasional-Extremely-Slow-Redraws-in-OSX-Emacs-tp318492p387421.html
Sent from the Emacs - Bugs mailing list archive at Nabble.com.

[Message part 2 (text/html, inline)]

Message #69 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bulldozer <kentdozier <at> gmail.com>
To: Bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Thu, 11 Feb 2016 22:10:51 -0700 (MST)

[Message part 1 (text/plain, inline)]

Unfortunately, Aquamacs with 25.0.50.5 is unusable due to spinning color
wheel when I come back to the window after using other apps. The more panes
I have open, the longer it takes to come back.  Sometimes it takes 10
minutes.  It's possible it is doing an even slower drawing update while the
wheel spins, but I don't see any obvious drawing like I did in the older
version.

On Wed, Feb 10, 2016 at 4:26 PM, Kent Dozier <kentdozier <at> gmail.com> wrote:

> Sure, I just downloaded the latest nightly with Emacs 25.0.50.5.  I'll use
> this for a while and report back.
>
> On Wed, Feb 10, 2016 at 3:31 PM, Alan Third [via Emacs] <
> ml-node+s1067599n387419h59 <at> n5.nabble.com> wrote:
>
>> bulldozer <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=387419&i=0>> writes:
>>
>> > Over a year later, I am also still experiencing the slow redraw,
>> usually when
>> > using the mouse wheel to scroll. I can see it slowly going down each
>> line,
>> > one split window at a time, redrawing the text. Aquamacs is
>> unresponsive
>> > until it finishes redrawing all visible text.
>> >
>> > O/S: Mac OSX 10.9.5
>> > Aquamacs 3.2 GNU Emacs 24.4.51.2
>> > x86_64-apple-darwin14.0.0, NS apple-appkit-1343.14
>>
>> Hi! I can't replicate this in Emacs 25. Would it be possible for you to
>> test it with Emacs 25 and see if you still get this problem?
>>
>> I'm not using Aquamacs, but I notice they have a preview of 25 available.
>> --
>> Alan Third
>>
>>
>>
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://emacs.1067599.n5.nabble.com/bug-17124-24-3-50-Occasional-Extremely-Slow-Redraws-in-OSX-Emacs-tp318492p387419.html
>> To unsubscribe from bug#17124: 24.3.50; Occasional Extremely Slow Redraws
>> in OSX Emacs, click here
>> <http://emacs.1067599.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=318492&code=a2VudGRvemllckBnbWFpbC5jb218MzE4NDkyfDkzMzc5MjgzNg==>
>> .
>> NAML
>> <http://emacs.1067599.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>




--
View this message in context: http://emacs.1067599.n5.nabble.com/bug-17124-24-3-50-Occasional-Extremely-Slow-Redraws-in-OSX-Emacs-tp318492p387548.html
Sent from the Emacs - Bugs mailing list archive at Nabble.com.

[Message part 2 (text/html, inline)]

Message #72 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bulldozer <kentdozier <at> gmail.com>
Cc: 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 12 Feb 2016 09:21:17 +0200

> Date: Thu, 11 Feb 2016 22:10:51 -0700 (MST)
> From: bulldozer <kentdozier <at> gmail.com>
> 
> Unfortunately, Aquamacs with 25.0.50.5 is unusable due to spinning color wheel when I come back to the
> window after using other apps. The more panes I have open, the longer it takes to come back. Sometimes it
> takes 10 minutes. It's possible it is doing an even slower drawing update while the wheel spins, but I don't see
> any obvious drawing like I did in the older version.

Isn't it true that Aquamacs is sufficiently different from Emacs to
consider it a separate project?  If so, I don't think we can solve
such problems in Aquamacs if they cannot be reproduced in upstream
Emacs builds.

Message #75 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bulldozer <kentdozier <at> gmail.com>, 17124 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Fri, 12 Feb 2016 23:54:37 +0000

On Fri, Feb 12, 2016 at 09:21:17AM +0200, Eli Zaretskii wrote:
> Isn't it true that Aquamacs is sufficiently different from Emacs to
> consider it a separate project?  If so, I don't think we can solve
> such problems in Aquamacs if they cannot be reproduced in upstream
> Emacs builds.

Well, I just downloaded Aquamacs to see if I could replicate it there
and I can't, so that doesn't help much.

BTW, in case it matters, I'm trying to get the slow refresh by
following these instructions from Eric Froemling:

> (basically open a large buffer, subdivide a frame into quite a few
> windows, and then vigorously shake a horizontal divider for a bit.
> In my case I usually get a slow refresh after 5-15 seconds).

As well as by scrolling up and down in a large buffer.

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

Message #80 received at 17124 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: bulldozer <kentdozier <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 17124 <at> debbugs.gnu.org, 16594 <at> debbugs.gnu.org
Subject: Re: bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs
Date: Wed, 09 Sep 2020 14:30:24 +0200

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

Previous Next

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