GNU bug report logs - #32932
27.0.50; render bugs on macOS Mojave

Previous Next

Full log

Message #80 received at 32932 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: Boris Buliga <boris <at> d12frosted.io>, 32932 <at> debbugs.gnu.org
Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Wed, 24 Oct 2018 11:42:42 +0100

On Mon, Oct 22, 2018 at 07:15:03PM -0700, Aaron Jensen wrote:
> On October 20, 2018 at 1:04:47 PM, Alan Third
> (alan <at> idiocy.org(mailto:alan <at> idiocy.org)) wrote:
> 
> > Can you try removing
> >
> > ns_clear_frame_area (emacsframe, x, y, width, height);
> >
> > from drawRect: in nsterm.m? It may result in the background not being
> > redrawn correctly in some places, but I *think* it’s redundant, and
> > it’s possible for it to clear a section of screen and then
> > expose_frame to decide not to redraw anything.
> >
> > This shouldn’t happen as the only reason I know for expose_frame to
> > not redraw is if there’s a redisplay coming up, in which case
> > redisplay should mark the whole frame as needing redrawn anyway. But
> > perhaps there’s some situation where it doesn’t draw and there’s no
> > immediate redisplay.
> 
> So far so good. I don’t believe I’ve seen aberrant paints/clears. I’ll
> keep using it for another week or so and report back.

I’ve pushed a slight variant of this change to emacs-26. I’ve
witnessed a very rare flicker of the modeline and the line containing
the cursor in other windows while scrolling, but I can’t replicate it
consistently.

I opened a large file (xdisp.c), set the frame up like so:
M-f10 C-x 3 C-x 2, and scrolled the top left window up and down as
fast as possible.

Thanks for your help with this.
-- 
Alan Third

Previous Next

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