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 1:26 PM Alan Third <alan@idiocy.org> wrote:
>
> This is one of the many reasons I walked away from the NS port. ;)

You are missed :)

> 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.

This one seems to be more about longer lines ghosting onto the tail
end of shorter lines. You could imagine that if you had a long line
and a short line, then scrolled such that the short line was where the
long line was but only repainted the area there were glyphs, the new
short line would include the tail end of the long line:

window line 2: xxxxxxxxxxxxxx
window line 3: yyyyyyyyyy
->
window 1: xxxxxxxxxxxxxx
window 2: yyyyyyyyyyxxxx

What do you think about what I mentioned later in the thread about:

[view setNeedsDisplayInRect:srcRect];

Why would that be srcRect and not destRect? Could that cause this somehow?

Thanks,

Aaron