bug#16967: frame related race condition

[Stefan Monnier <monnier@iro.umontreal.ca>]

>   /* 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