On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

Aaron Jensen <aaronjensen@gmail.com> 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 <aaronjensen@gmail.com> 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.