bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS

[Aaron Jensen <aaronjensen@gmail.com>]

On Sun, Apr 30, 2023 at 10:42 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: 63187@debbugs.gnu.org
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Sun, 30 Apr 2023 10:25:59 -0400
> >
> > On Sun, Apr 30, 2023 at 9:25 AM Po Lu <luangruo@yahoo.com> wrote:
> > >
> > > Hmmm, this looks like a scrolling optimization bug.
> > > I can't build the NS port right now, but if you insert:
> > >
> > >   return false;
> > >
> > > right after
> > >
> > >   /* Can't scroll the display of w32 GUI frames when position of point
> > >      is indicated by the system caret, because scrolling the display
> > >      will then "copy" the pixels used by the caret.  */
> > > #ifdef HAVE_NTGUI
> > >   if (w32_use_visible_system_caret)
> > >     return 0;
> > > #endif
> > >
> > > in `scrolling_window', in dispnew.c, does the problem go away?
> >
> > Thanks, I will try this out. Is there any chance that it is related to
> > the other bug I just reported, bug#63186?
>
> No, no chance.  That bug was system-independent, while this one is
> specific to macOS.  Also, while investigating bug#63186, I've
> established that disabling scrolling_window optimization doesn't fix
> the problem with redisplaying the mode line after mode-line-format was
> nil.

Copy that.

> > Is there anything specific to macOS that is involved in scrolling optimization?
>
> Not that I know of, and so if Po Lu's suggestion fixes the problem,
> we'd need to understand how come scrolling_window fails on macOS.

Ok, it may take me a few days to be sure. It happens intermittently,
though lately it has been at least once in most work days.

For what it's worth, disabling it has had no discernible impact on
scroll performance on my machine (which is an M1)

Aaron