bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Third
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Fri, 9 Jun 2023 19:27:41 +0100

On Fri, Jun 09, 2023 at 11:12:47AM +0800, Kai Ma wrote:
> 
> 
> > On Jun 9, 2023, at 10:47, Aaron Jensen <aaronjensen@gmail.com> wrote:
> > 
> > On Thu, Jun 8, 2023 at 10:42 PM Kai Ma <justksqsf@gmail.com> wrote:
> >> 
> >> Increasing CACHE_MAX_SIZE alone doesn’t seem to help much.
> >> (Screencast: https://www.youtube.com/watch?v=9YD9jyP-GKw)
> >> 
> >> Increasing CACHE_MAX_SIZE + Removing performSelectorOnMainThread seems to 
> >> be better but I can’t be sure.  Just observed:
> >> 
> >> (1) M-< at the mid of a buffer, but only the first line of the view is 
> >> refreshed, and other parts were still there.
> >> 
> >> (2) selecting a region doesn’t always clear the hl-line effect.
> > 
> > What are you doing to make your background translucent? I've never
> > seen anything nearly as bad as what you have. I've only seen a glitch
> > maybe once since the last patch (and that may have even been something
> > else). It makes me wonder if there's something else different/off
> > about your setup.
> 
> (set-frame-parameter nil 'alpha 0.95)
> 
> Indeed I haven’t been able to reproduce this bug in emacs -q so far.
> I thought I didn’t do anything unconventional, but, well,
> polling-period seems to be the culprit.
> 
> I had in my config
>   (setq polling-period 0.01)
> to increase the responsiveness of C-g, and reverting the change to
> the default value 2.0 is effective.

Well, I have no idea what that actually means in terms of the display.

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.

(And it should probably be [view setNeedsDisplay:YES] if it's needed
there at all.)

If tearing becomes a wider problem probably the best option would be
to actually wait for a surface to become free before taking it off the
cache, but... I dunno. I don't really know how we do that without just
having a loop polling continuously. Sleep for a few milliseconds each
time round the loop?

-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]