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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Mon, 30 Jun 2014 14:55:22 +0200
> Cc: ericfroemling@gmail.com,
>  17124@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.