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

Previous Next

Full log

Message #347 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: Sun, 26 Feb 2023 19:00:32 +0200

On 26/02/2023 17:54, Gregory Heytings wrote:
> 
>>>> To avoid this measurement affecting the delay itself, as we saw with 
>>>> printfs and trace-redisplay, the timings should be sent via pipe to 
>>>> a file, not to the screen.
>>>
>>> If they indeed don't affect the measurement when they are sent to a 
>>> file, it is probably possible to sent them to the screen without 
>>> affecting the measurement, by calling 'tail -f' on the file in which 
>>> they are recorded in another terminal.
>>
>> Yes, I suppose this can work, if the new terminal is positioned far 
>> away from Emacs's window.
>>
>> None of the new proposed tests depend on me being able to monitor the 
>> output in real time, though.
>>
> 
> If you want to measure the latency between the moment an XFlush is 
> issued by Emacs and the moment you actually see the buffer contents of 
> the buffer on screen, I think you could screencast your repro and use 
> the recorded video to make that measurement (unless screencasting 
> eliminates the problem, too...).

Its weird: screencast recording doesn't stop the problem from happening 
live, but it fails to capture how it looks.

I've recorded a half dozen of such screencasts, and I think only one of 
them managed to capture the desynchronization between the title bar and 
the window update. The rest look like there is no delay.

But this one occurrence you can see here (attempt #4, around 00:00:06):

https://a.uguu.se/Oopgcemf.webm

Previous Next

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