[Top][All Lists]

[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: Alan Third
Subject: bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized
Date: Mon, 12 Mar 2018 00:46:38 +0000
User-agent: Mutt/1.9.3 (2018-01-21)

On Sun, Mar 11, 2018 at 06:29:05PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Mar 2018 23:07:06 +0000
> > From: Alan Third <address@hidden>
> > Cc: address@hidden, address@hidden
> > 
> > > 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?

OK, so this plan is a non‐starter.

Can I check an assumption I’m making?

Am I able to call redisplay whenever I want? That is, does calling it
ever result in a longjmp?

Alan Third

reply via email to

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