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

[Alan Third <alan@idiocy.org>]

On Mon, May 01, 2023 at 04:25:05PM +0300, Eli Zaretskii 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.

This is one of the many reasons I walked away from the NS port. ;)

I'm 99% certain that [EmacsView copyRect:] is correct. I went over it
numerous times. It's just doing a simple copy of one rectangle of a
graphics buffer to another, identically sized, rectangle. It handles
overlapping rectangles and there's really not very much logic in it to
go wrong.

Po Lu asks about how it synchronises with the system, and it doesn't
really have to. The system draws into the same buffer that copyRect
accesses. It does make me wonder if there's a rare occasion when
copyRect is called and the system hasn't flushed all it's drawing
instructions to the buffer yet. It's probably possible to force it to
flush by doing something like:

    [[NSGraphicsContext currentContext] flushGraphics];

at the top of copyRect. Preferably only on macOS 10.14 and above, but
it probably makes no difference on other platforms since scrollRect
should force a flush anyway.

My memory of Aaron's previous bug report about this was that it looked
like, in some cases at least, the rectangle being copied was too wide
and copyRect, not being very smart, was just wrapping off the edge of
the buffer onto the next row of pixels, but I couldn't find any reason
for that to happen since afaik all the callers check the Emacs window
size so should never ask to copy a too-wide rectangle.

-- 
Alan Third