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

[Daniel Colascione <dancol@dancol.org>]

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: 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.
>
> Sure.
>

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.