bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@swipnet.se>
> Date: Fri, 27 Jun 2014 19:13:00 +0200
> Cc: ericfroemling@gmail.com,
>  17124@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).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]