GNU bug report logs - #77039
31.0.50; Flickering on macOS

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
Subject: bug#77039: 31.0.50; Flickering on macOS
Date: Tue, 18 Mar 2025 18:52:08 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 18 Mar 2025 15:32:41 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org, 
> 	77039 <at> debbugs.gnu.org
> 
>  Yes, redisplay should be a nop, since the buffer which is modified is not displayed. 
> 
>  But Aaron seems to say we keep comparing the glyph matrices of the window which is not show,
>  something that should not happen, because we don't call update_frame on frames that are not visible.
> 
> I tried to explain that I wasn't convinced that it was that, that it could have, and even likely was, a redisplay of
> the currently displayed buffer (which is why *it* was flickering). Unless anyone thinks that there is reason to
> investigate further, I'm satisfied with the answer that reading process output can cause a comparison of
> glyphs, which is unlikely to result in a redisplay of an unrelated buffer.

Reading process output is not supposed to cause comparison of glyphs
if the buffer to which process output is directed is not being
displayed.  So if you do see glyphs being compared in that case, we
should look into that.  The only glyphs that could be legitimately
compared in that case are those on the mode line.

> If you'd like me to try the FILE/LINE logging, please let me know and I'd be happy to do it. 

If the above means you see something that shouldn't happen, then yes,
please provide the traces.

Previous Next

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