Re: RFC: flicker-free double-buffered Emacs under X11

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 27 Oct 2016 12:06:25 -0700
> From: dancol@dancol.org
> Cc: Daniel Colascione <dancol@dancol.org>, Ken Raeburn <raeburn@raeburn.org>,
> 	emacs-devel@gnu.org
> 
> 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.

Thanks again for working on this.