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

Previous Next

Full log

View this message in rfc822 format

From: Eric Froemling <ericfroemling <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17124 <at> debbugs.gnu.org
Subject: 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.

Previous Next

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