GNU bug report logs - #30699
26.0.91; buffer contents flicker on macOS frames when frames are resized

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sun, 4 Mar 2018 17:39:01 UTC

Severity: normal

Tags: fixed

Found in version 26.0.91

Fixed in version 27.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#30699: 26.0.91; buffer contents flicker on macOS frames when
 frames are resized
Date: Sat, 10 Mar 2018 23:07:06 +0000
On Sat, Mar 10, 2018 at 10:30:27AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Mar 2018 00:25:55 +0000
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
> > 
> > diff --git a/src/nsterm.m b/src/nsterm.m
> > index 1919c6defa..b4ec384aaf 100644
> > --- a/src/nsterm.m
> > +++ b/src/nsterm.m
> > @@ -288,6 +288,7 @@ - (NSColor *)colorUsingDefaultColorSpace
> >  static BOOL ns_fake_keydown = NO;
> >  #ifdef NS_IMPL_COCOA
> >  static BOOL ns_menu_bar_is_hidden = NO;
> > +static int disable_screen_updates_count = 0;
> 
> Doesn't making this static mean potential trouble if redisplay is run
> from a non-main thread?

I’m not aware of any problems with global static variables, but I’m
certainly no expert. What is the risk?

> > diff --git a/src/xdisp.c b/src/xdisp.c
> > index 9170d6b777..d4fdb44b32 100644
> > --- a/src/xdisp.c
> > +++ b/src/xdisp.c
> > @@ -14599,6 +14599,9 @@ redisplay_internal (void)
> >   end_of_redisplay:
> >  #ifdef HAVE_NS
> >    ns_set_doc_edited ();
> > +#ifdef NS_IMPL_COCOA
> > +  ns_enable_screen_updates ();
> > +#endif
> >  #endif
> 
> Can x_set_window_size be called only from redisplay_internal?  If not,
> doesn't this risk leaving the updates disabled, if x_set_window_size
> is called from some other place?

No, I believe it’s never called from redisplay_internal. 

But x_set_window_size always leaves the frame blank (and there’s no
way round that as far as I can see), so there’s not much risk in
disabling screen updates until redisplay completes. All we’re doing is
preventing the user from seeing a blank frame.

Or is there some way for the frame to be redrawn other than redisplay
or expose_frame?

> Also, redisplay_internal has a few early returns which don't go
> through end_of_redisplay -- are you sure they can never happen in this
> situation?  For example, what if popup_activated returns non-zero?

Nope. Is there a better place to put it? For example is there a hook
that runs when redisplay exits?

-- 
Alan Third




This bug report was last modified 7 years and 112 days ago.

Previous Next


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