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

[Aaron Jensen <aaronjensen@gmail.com>]

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?

> As I recall locking is really just setting a flag saying it's
> currently being used so nobody else should touch it, it doesn't stop
> you from doing things with it.
>
> I know, for example, that it's possible to write to a surface that's
> been locked by the transfer to VRAM, and that results in tearing
> effects where the copy in VRAM is half updated. The VRAM copy isn't
> ever copied back down to system RAM, though, so it doesn't have any
> permanent consequences beyond a tearing effect at that particular
> moment.

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?

Aaron