Subject: bug#77039: 31.0.50; Flickering on macOS

From: Gerd Möllmann <[email-masked]>
Date: Tue, 18 Mar 2025 08:55:21 +0100

Gerd Möllmann <[email-masked]> writes:

> 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.
>
> Why wait_reading_process_output is called with argument do_display ==
> true I have no idea.

>From reading the code a bit, where wait_reading_process_output is
called, calling it with do_display == true looks okay to me. It is
sometimes necessary to redisplay, and checking the cases where it isn't
is probably similarly expensive as just doing the redisplay.

So, I propose to close the bug.