Subject: bug#77039: 31.0.50; Flickering on macOS

From: Eli Zaretskii <[email-masked]>
Date: Tue, 18 Mar 2025 15:19:00 +0200

> From: Gerd Möllmann <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [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.