[Top][All Lists]

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

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

From: Daniel Colascione
Subject: Re: RFC: flicker-free double-buffered Emacs under X11
Date: Thu, 27 Oct 2016 12:56:41 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/27/2016 12:44 PM, Daniel Colascione wrote:
On 10/27/2016 12:36 PM, Eli Zaretskii wrote:
Date: Thu, 27 Oct 2016 12:06:25 -0700
From: address@hidden
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
and resizing.


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

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.


By the way: why would we ever _want_ to allow redisplay to return without having redrawn all garbaged frames? The design of redisplay suggests that a postcondition on redisplay_internal should be that there's nothing left to draw, at least in the case that we weren't interrupted by input.

reply via email to

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