Date: Thu, 27 Oct 2016 12:06:25 -0700
Cc: Daniel Colascione <address@hidden>, Ken Raeburn
Below is a new much-improved version of the patch. It should address the
legibility concerns while probably adding more. It addresses all the
I've been able to find and on my machine, produces buttery smooth
Why _do_ we have a path that short-circuits the rest of the redisplay
code? What would happen if we just removed it? It appears to be some
kind of optimization, and I'm not sure it's actually necessary
(especially since, according to the comment, we disable it anyway
case of a blinking cursor).
It's an optimization for the case that nothing needs to be
Isn't the "goto update" path fast enough?
That would still call hscroll_windows and update_frame, which is just
waste of cycles when we know nothing's changed.
@@ -14072,6 +14072,17 @@ redisplay_internal (void)
if (!f_redisplay_flag && f->redisplay)
+ /* In some case (e.g., window resize), we notice
+ only during window updating that the window
+ content changed unpredictably (e.g., a GTK
+ scrollbar moved) and that our previous estimation
+ of the frame content was garbage. We have to
+ start over. These cases should be rare, so going
+ all the way back to the top of redisplay should
+ be good enough. */
+ if (FRAME_GARBAGED_P (f))
+ goto retry;
This worries me a bit: FRAME_GARBAGED_P returns non-zero for TTY
frames very frequently, whereas at least the comment seems to imply
this is needed only for GUI frames, perhaps even only in GTK builds.
If that is correct, then perhaps add a FRAME_WINDOW_P test here, to
avoid unnecessarily slowing down redisplay.