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

[Alan Third <alan@idiocy.org>]

On Sat, Jun 24, 2023 at 10:52:08AM -0400, Aaron Jensen wrote:
> On Sat, Jun 24, 2023 at 10:14 AM Alan Third <alan@idiocy.org> wrote:
> >
> > On Sat, Jun 24, 2023 at 09:34:18AM -0400, Aaron Jensen wrote:
> > >
> > > Could you try removing the destination lock as well and see if that
> > > impacts anything? From what I can tell, locking the destination may be
> > > a good idea, but I'm curious if Alan has any thoughts as to why it'd
> > > be a bad idea.
> >
> > copyContentsTo is only called by getContext, which has already locked
> > the destination, so there's no need to lock it again.
> 
> Ah, I see. Is the kIOSurfaceLockAvoidSync flag valuable for any reason?

I don't think so... Not in our use-case. IIRC it's possible to get the
GPU to perform actions on the buffer once it's in VRAM. We don't do
that, so we don't need to ever worry about write-backs to system RAM.

I think.

> If I recall correctly, there's some code in Emacs that optimizes which
> areas of the screen glyphs are drawn to. Maybe it remembers what was
> the background color already and doesn't clear it again... I don't
> remember where I saw it, but I think it was outside of nsterm. Does
> that ring a bell? I'm thinking about how this manifests. For me, it's
> always whole characters that are painted, they are always painted in
> what would otherwise be whitespace, and they tend to get "copied" to
> the next line in the whitespace as scrolling happens. In other words,
> it doesn't just seem like a fluke write during the transfer to VRAM.
> It seems like something in the engine is writing them, that the state
> is getting "stuck" somehow. Does any of that ring a bell/jog anything?

Its quite possible. I did say before in the thread that it seems quite
possible to me that something isn't clearing the whitespace correctly.
But it's obviously rare, and I would expect that it's some piece of NS
port code rather than somewhere else.

Unless there's something that's #ifdef'd out because at some point in
the past the NS port has behaved differently...

But more likely if this is what's going on then it's going to be a bug
in the NS port. Unfortunately I don't really understand how the glyph
drawing side works, and never did.

But if that's the case, why would removing the asynchronous call to
getContext fix so many problems?

Something perhaps worth trying... Since removing the asynchronous call
to getContext fixes the problems, perhaps we need to think about the
"lazy" way we get the next buffer when the current one is displayed.
At the moment it just forgets about it until we want to draw to the
screen, at which point we call getContext and it creates the buffer if
necessary and copies the old one to the new one.

Maybe we should get the new buffer and do the copy when we set the
current buffer for display...

IIRC I avoided that because there isn't always time for the buffer to
have been sent to VRAM and unlocked before the *next* call to display,
so I wanted to leave it as long as possible between display and
getting the next buffer, but maybe this is just the wrong way to do
it.

So I suppose putting a call to getContext right after "currentSurface
== NULL" in display might be a quick and dirty way to test that.

-- 
Alan Third