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

[Alan Third <alan@idiocy.org>]

On Tue, May 02, 2023 at 03:21:46PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 May 2023 11:14:56 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>,
> > 	63187@debbugs.gnu.org
> > 
> > Although, on reflection, your description sounds more like it's just
> > not clearing the end of lines correctly, which wouldn't necessarily
> > have anything to do with scrolling as such...
> 
> Can that happen in this case?  You will see in the code that (AFAIU)
> it copies a rectangle whose width is the total width of the window, so
> why would (not) clearing ends of lines be an issue?

It depends where the actual problem is occurring. It's hard to tell
from the screenshots whether the rogue glyphs appear spontaneously in
the middle of the window, or as a new line is scrolled onto the
screen.

If it's the latter then obviously the procedure is to clear the line
that's to be drawn, then draw the new content, however if the clearing
isn't done correctly then you end up with the end of the line that was
there previously still visible to the right of the new content.

As it scrolls further, Emacs no doubt is clever enough to know that it
doesn't need to clear more than it drew for the last line, so the
rogue characters at the end stay for the subsequent line, and so on
until it hits a line that is long enough to wipe it all out.

I hope I'm explaining this well enough.

Either way, I don't know why it would be happening.
-- 
Alan Third