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


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized
Date: Sun, 11 Mar 2018 18:29:05 +0200
> Date: Sat, 10 Mar 2018 23:07:06 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
> 
> > > +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?

That one thread sets the variable, and another tries to use the value,
believing that it was set by that other thread.

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

Then how do we guarantee that these two calls, one from
x_set_window_size, the other from redisplay_internal, will be
balanced, and you never end up with screen updates disabled when you
don't intend?

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

The question is: can x_set_window_size be called without a redisplay
happening soon enough, e.g. if Emacs is busy doing some lengthy
calculation?

> > 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?

Unless I'm misremembering, I don't think there is such a hook.




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.