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

[Aaron Jensen]

On Mon, May 1, 2023 at 9:24 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: aaronjensen@gmail.com,  63187@debbugs.gnu.org
> > Date: Mon, 01 May 2023 21:18:31 +0800
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> Cc: 63187@debbugs.gnu.org
> > >> Date: Mon, 01 May 2023 07:58:26 +0800
> > >> From:  Po Lu via "Bug reports for GNU Emacs,
> > >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > >>
> > >> Aaron Jensen <aaronjensen@gmail.com> writes:
> > >>
> > >> > Is there anything specific to macOS that is involved in scrolling 
> > >> > optimization?
> > >>
> > >> Yes, Apple deleted the API used to perform bit blits, so Emacs uses a
> > >> workaround that I don't really understand, and seems unreliable.
> > >
> > > You mean, ns_scroll_run in nsterm.m?  Which parts of it do you not
> > > understand?
> >
> > No, I meant the implementation of [EmacsView copyRect:] enabled under
> > Mac OS; see line 8655 of nsterm.m.  I don't understand how the system
> > synchronizes its access to the window's backing store with Emacs's.
>
> Alan, can you help?
>
> If this is unworkable on macOS, we could simply disable this
> optimization there.  But note that scroll_run_hook is also called from
> xdisp.c, in several places, so we may need to disable it there as
> well.

Is this suspect?

  {
    NSRect srcRect = NSMakeRect (x, from_y, width, height);
    NSPoint dest = NSMakePoint (x, to_y);
    EmacsView *view = FRAME_NS_VIEW (f);

    [view copyRect:srcRect to:dest];
#ifdef NS_IMPL_COCOA
    [view setNeedsDisplayInRect:srcRect];
#endif
  }

Why is the source being marked for redisplay? I would expect the
destination to be marked as such, or am I missing something?