Subject: Re: bug#77039: 31.0.50; Flickering on macOS

From: Aaron Jensen <[email-masked]>
Date: Sun, 16 Mar 2025 16:43:27 +0000

On Sun, Mar 16, 2025 at 4:49 AM, Ship Mints <[email-masked]> wrote:

> On Sun, Mar 16, 2025 at 2:05 AM Aaron Jensen <[email-masked]>
> wrote:
>
>> On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <[email-masked]>
>> wrote:
>>
>>> Aaron Jensen <[email-masked]> writes:
>>>
>>> Adding Gerd Möllmann.
>>>
>>> The flicker appears to have been introduced by the work done in
>>> 414de92a562
>>>
>>> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
>>> months ago) <Gerd Möllmann>
>>>
>>> It's a fairly large change set, so I don't know yet what might be
>>> causing it. I can reproduce it fairly consistently using my own setup, but
>>> I don't know how to narrow it down to something from Emacs -Q because it
>>> appears to be related to CPU utilization and/or rapid updating of buffers
>>> that are not currently visible.
>>>
>>> Aaron
>>>
>>> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <[email-masked]>
>>> wrote:
>>>
>>> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>>>
>>> It seems to happen more often when there is significant load. In this
>>> case, I was running an 8 worker web server in a vterm in Emacs and a set of
>>> 8 parallel UI tests against it. The server was printing log messages at a
>>> rapid rate, but that vterm buffer was not visible.
>>>
>>> Aaron
>>>
>>> I'm afraid I have not the slightest idea.
>>>
>>> 414de92a562 concerns only ttys, AFAICT. I've looked through the commit
>>> again right now. The changes to NS code directly are only trivial ones
>>> (1 -> true, 0 -> false etc.). So it would have to be something in
>>> redisplay_internal or something similar, in code not specific to NS that is
>>> used on all window systems, and I don't see a change there that could cause
>>> something with the symptoms you describe.
>>>
>>> Adding Alan Third in CC. Maybe he has an idea.
>>>
>>
>> I'll try and eliminate aspects of the patch as best as I can. If this is,
>> in fact, a macOS only issue, then it may be that the particular method of
>> drawing the windows in macOS is susceptible to some change that was made
>> here. No idea what it could be, either. I do see that the NS-specific
>> changes appear to be innocuous.
>>
>
> What is your frame-parameter inhibit-double-buffering set to?  Have you
> tried flip-flopping it to see if that has an impact?
>

I usually have it set to true,  but yes, changing it was the first thing I
tried. It seems to reduce the overall impact of the flicker (at least when
I tried it again just now), but it still happens even when double buffering
is enabled.