Date: Thu, 27 Oct 2016 12:06:25 -0700
From: address@hidden
Cc: Daniel Colascione <address@hidden>, Ken Raeburn
<address@hidden>,
address@hidden
Below is a new much-improved version of the patch. It should address the
legibility concerns while probably adding more. It addresses all the
bugs
I've been able to find and on my machine, produces buttery smooth
editing
and resizing.
Thanks.
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
in the
case of a blinking cursor).
It's an optimization for the case that nothing needs to be
redisplayed.
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)
goto retry_frame;
+ /* 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.