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: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Kai Ma <justksqsf <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 63187 <at> debbugs.gnu.org
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Fri, 9 Jun 2023 21:00:19 +0100

[Message part 1 (text/plain, inline)]

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

[0001-Reduce-graphical-glitches-in-certain-circumstances-o.patch (text/x-diff, attachment)]

Previous Next

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