GNU bug report logs - #63187
30.0.50; Tail of longer lines painted after end of nearby lines on macOS

Previous Next

Full log

View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Aaron Jensen <aaronjensen <at> gmail.com>, Kai Ma <justksqsf <at> gmail.com>,  63187 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Mon, 12 Jun 2023 09:04:47 -0400

On Fri, Jun 9, 2023 at 4:00 PM Alan Third <alan <at> idiocy.org> wrote:
>
> On Fri, Jun 09, 2023 at 02:46:29PM -0400, Aaron Jensen wrote:
> > On Fri, Jun 9, 2023 at 2:27 PM Alan Third <alan <at> idiocy.org> wrote:
> > > It seems to me that removing the call to performSelectorOnMainThread
> > > should be done. That may even fix Aaron's original issue too, given
> > > that I don't know why calling setNeedsDisplayInRect twice in a row
> > > should help, especially given it's not actually used anywhere else in
> > > the display code.
> >
> > How is it called twice? Does copyRect mark for redisplay?
>
> Sorry, I had misunderstood your change.
>
> Either way, I don't see how it's made a difference.
> setNeedsDisplayInRect is telling the system which parts it needs to
> call drawRect on, but we don't use drawRect any more, so I would think
> all it can be doing is setting the needsDisplay boolean to true.
>
> copyRect definitely doesn't do anything with the rectangle. It deals
> with the bitmap's pixel data directly, so there's no clipping or
> anything else affecting it and it's changes don't need to be
> committed to some backing store.
>
> Even when it comes to actually displaying the view on the screen, we
> pass in the entire bitmap to the graphics subsystem and it
> (supposedly) displays it in it's entirety.
>
> So as I understand it the rectangle passed into setNeedsDisplayInRect
> doesn't do anything. I think that call in ns_scroll_run was left there
> by mistake. It's literally the only call to it in the entire nsterm.m
> file.
>
> But you report that it has fixed your problem. I can't explain that
> because it runs counter to my understanding of how macOS draws.
>
> But then again, none of this is documented in any in-depth way by
> Apple, so who knows what's REALLY going on.
>
> Patch attached, but it's untested. It may even make things worse. I'm
> happy to leave it up to you to decide what to do since you're in a
> better position to tell if any given change actually helps.

Thanks, I'm trying it out now. I'll report back in a bit. If it's fine
I'll try removing the setNeedsDisplay as well and try again.

Aaron

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.