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

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org,
 77039 <at> debbugs.gnu.org
Subject: Re: bug#77039: 31.0.50; Flickering on macOS
Date: Tue, 18 Mar 2025 15:32:41 +0000

[Message part 1 (text/plain, inline)]

On Tue, Mar 18, 2025 at 6:19 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz@
> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org Date: Tue, 18 Mar 2025
> 07:02:53 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Not Lisp, but:
>
> emacs -Q
> M-x shell
> yes<enter>
> C-x b<enter>
>
> This will open a shell in a background buffer that is rapidly printing to
> STDOUT (and displaying in the shell buffer) then switch to the scratch
> buffer. If you add logging to the matrix comparisons you will see a rapid
> uptick. I don't know if this has to do with the external process connection
> with Emacs.
>
> To be clear, I don't know if this is actually an issue given that the
> matrix comparison is likely preventing the redisplay.
>
> Aaron
>
> When I configure with --enable-checking=glyphs, and run, in emacs -Q, GUI
> version the function
>
> (defun foo ()
> (interactive)
> (trace-redisplay 1)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> I see traces of the form
>
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> ...
>
> The 12 means the call is from wait_reading_process_output, which reads the
> output from /usr/bin/yes in this case.
>
> So, that explains where the redisplay comes from. Since there are no
> further redisplay actions shown in the trace output, I think that redisplay
> is more or less a nop in these cases. Didn't try without the fix that I
> pushed.
>
> 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.

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

Thanks,

Aaron

[Message part 2 (text/html, inline)]

Previous Next

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