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

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

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


From: Eli Zaretskii
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 <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > > +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.





reply via email to

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