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

Previous Next

Full log

View this message in rfc822 format

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: bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized
Date: Mon, 12 Mar 2018 00:46:38 +0000

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 <alan <at> idiocy.org>
> > Cc: 30699 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
> > 
> > > 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

Previous Next

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