bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized

[Eli Zaretskii]

> Date: Sat, 10 Mar 2018 23:07:06 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 30699@debbugs.gnu.org, aaronjensen@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.