GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Tue, 21 Feb 2023 02:55:01 UTC

Severity: normal

Found in version 29.0.60

Full log


Message #356 received at 61667 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61667: 29.0.60; Failure to redisplay
Date: Mon, 27 Feb 2023 22:55:00 +0200
On 27/02/2023 12:30, Gregory Heytings wrote:
>>
>> I redid the screencast using ffmpeg and x11grab, and it captures the 
>> problem fine. See the last two attempts (out of 6) in this video:
>>
>> https://a.uguu.se/PThfScNL.webm
>>
>> Note I also added (insert "!") and (redisplay) so that it's easy to 
>> see the exact moment "a" was pressed.
>>
> 
> Thanks!  After seeing this, I'm now convinced that the problem is not a 
> GNOME one, for two reasons:
> 
> 1.  The effect of (insert "!") (redisplay) is immediately visible on 
> screen.  Why would GNOME treat the effect of changing the buffer from 
> *scratch* to xassociations.rb differently?
> 
> 2. The delay is different with emacs -Q (13 frames in that video, which 
> at 25 FPS means 520 ms) and with your config.  Why would GNOME treat the 
> same app differently depending on how it is configured?

Thank you. At the very least it seems to mean that Mutter isn't outright 
broken.

There seems to be some problem regarding synchronization around the 
setting of the frame title.

One of the sides is subtly wrong -- not sure which one -- but other 
applications don't seem to exhibit the same buffering problem, so some 
sequence of action which would fix our situation should exist.




This bug report was last modified 1 year and 62 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.