Subject: bug#77039: 31.0.50; Flickering on macOS

From: Aaron Jensen <[email-masked]>
Date: Tue, 18 Mar 2025 15:32:41 +0000

On Tue, Mar 18, 2025 at 6:19 AM, Eli Zaretskii <[email-masked]> wrote:

> From: Gerd Möllmann <[email-masked]> Cc: Eli Zaretskii <eliz@
> gnu.org>, [email-masked], [email-masked] Date: Tue, 18 Mar 2025
> 07:02:53 +0100
>
> Aaron Jensen <[email-masked]> 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