[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16967: frame related race condition
From: |
Stefan Monnier |
Subject: |
bug#16967: frame related race condition |
Date: |
Wed, 12 Mar 2014 10:06:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> /* 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
- bug#16967: frame related race condition, (continued)
- bug#16967: frame related race condition, martin rudalics, 2014/03/10
- bug#16967: frame related race condition, Juanma Barranquero, 2014/03/10
- bug#16967: frame related race condition, martin rudalics, 2014/03/10
- bug#16967: frame related race condition, Juanma Barranquero, 2014/03/10
- bug#16967: frame related race condition, martin rudalics, 2014/03/10
- bug#16967: frame related race condition, Juanma Barranquero, 2014/03/10
- bug#16967: frame related race condition, martin rudalics, 2014/03/10
- bug#16967: frame related race condition, Juanma Barranquero, 2014/03/10
- bug#16967: frame related race condition, martin rudalics, 2014/03/11
- bug#16967: frame related race condition, Juanma Barranquero, 2014/03/11
- bug#16967: frame related race condition,
Stefan Monnier <=
- bug#16967: frame related race condition, martin rudalics, 2014/03/14
- bug#16967: frame related race condition, Stefan Monnier, 2014/03/14
- bug#16967: frame related race condition, Stefan Monnier, 2014/03/10
- bug#16967: frame related race condition, martin rudalics, 2014/03/11