bug#17124: 24.3.50; Occasional Extremely Slow Redraws in OSX Emacs

[Eric Froemling]

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
Description: Text document

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

>> From: Eric Froemling <ericfroemling@gmail.com>
>> Date: Fri, 28 Mar 2014 09:19:41 -0700
>> Cc: 17124@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.