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

Previous Next

Full log

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.

Previous Next

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