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

[Daniel Martín]

Alan Third <alan@idiocy.org> writes:

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

Could we add some tracing (or assertions) to the NS port, to help
understand this problem better?  I've also seen some rogue characters
from time to time (not frequently, and my Emacs sessions last long).  I
think it all started since the migration to IOSurface, but I'm not sure.
I don't have clear steps to reproduce yet.