GNU bug report logs - #16967
frame related race condition

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 16967 <at> debbugs.gnu.org
Subject: bug#16967: frame related race condition
Date: Wed, 12 Mar 2014 10:06:18 -0400

>   /* Nonzero if the frame is currently displayed; we check
>      it to see if we should bother updating the frame's contents.

>      On ttys and on Windows NT/9X, to avoid wasting effort updating
>      visible frames that are actually completely obscured by other
>      windows on the display, we bend the meaning of visible slightly:
>      if equal to 2, then the frame is obscured - we still consider
>      it to be "visible" as seen from lisp, but we don't bother
>      updating it.  */
>   unsigned visible : 2;

Hmm... I didn't realize this "visible=2" is also used in the Windows GUI.
So maybe the "visible=2" case under Windows is indeed mishandled by the
"redisplay bit" code.  Or by some other part of the code.

At least frame.h does:

   SET_FRAME_VISIBLE (struct frame *f, int v)
   {
     eassert (0 <= v && v <= 2);
     if (v == 1 && f->visible != 1)
       redisplay_other_windows ();
     f->visible = v;
   }

so it should handle the w32 case correctly.

> is likely responsible for the fact that Emacs doesn't always redisplay a
> frame when I remove the window of another application obscuring it.  I'm
> still convinced that we should call SET_FRAME_VISIBLE, at least when
> f->visible equals 2, in SIZE_RESTORED.

I'm not sure what SIZE_RESTORED is for, but indeed when we receive
a size-change notification, the "visible=2" optimization might not be
valid any more so we should set it back to 1.

And we should probably also set it back to 1 when we receive expose
events on that frame.

But I'm generally clueless about GUI code, and even more clueless about
w32, so please don't take my word for it.

> BTW: The more I look into this, the more I'm convinced that implementing
> frame parameters on top of the old frame infrastructure was one of the
> worst design ideas ever.

I have no idea what this is referring to.


        Stefan

Previous Next

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