[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GTK frame changes
From: |
Stephen J. Turnbull |
Subject: |
Re: GTK frame changes |
Date: |
Fri, 03 Jul 2009 21:14:59 +0900 |
grischka writes:
> Jan Djärv wrote:
> > The XProtocol specification (the oldest I have is R6.8, the newest is
> > 7.4, they say the same thing) says this:
> >
> > "Whether or not a server is implemented with internal
> > concurrency, the overall effect must be as if individual requests
> > are executed to completion in some serial order, and requests
> > from a given connection must be executed in delivery order (that
> > is, the total execution order is a shuffle of the individual
> > streams).
Jan is missing a number of issues, I think. First, there are (at
least) two clients and *two* connections involved here. One is
Emacs's, the other is the WM's. This leaves a lot of room for
nondeterminism ("shuffling") in the order in which configuration
events arrive on Emacs's connection.
Second, the process that generates the ConfigureNotify event is *not*,
and cannot be, atomic. When the WM has set the SubstructureRedirect
flag on the root window, a request by Emacs to configure one of its
(X) windows will propagate up the toolkit hierarchy to a shell window,
which will then execute X protocol. However the reaction of the
server to that protocol request is *not* to configure the window and
send a ConfigureNotify event. It is to *do nothing* except send a
ConfigureRequest event to the window, which will be processed by the
WM (because of the substructure redirection), not Emacs. The WM *then
issues the configuration request again*, which will succeed this time
because the WM "owns" the substructure redirection.
> I'm somehow confused what they mean by reply here. If events are sent
> before replies then replies must be something else.
Yes. An event is sent as a reaction to something that happens to or
in a window. A reply is something that the server says as an
informational matter in response to a request, which doesn't need to
specifically refer to any window.
> Just with WM redirection (metacity here) the ConfigureNotify
> clearly arrives about 2 ms later and the behavior is completely
> unimpressed by XSync.
"metacity"? As a developer of an X client, that's not my favorite
WM.... metacity's idea of "well-behaved" is a bit more restrictive
than fdo's standards specify.
- GTK frame changes, grischka, 2009/07/02
- Re: GTK frame changes, Jan Djärv, 2009/07/02
- Re: GTK frame changes, grischka, 2009/07/02
- Re: GTK frame changes, Jan Djärv, 2009/07/02
- Re: GTK frame changes, grischka, 2009/07/02
- Re: GTK frame changes, Jan Djärv, 2009/07/02
- Re: GTK frame changes, grischka, 2009/07/03
- Re: GTK frame changes, Jan Djärv, 2009/07/03
- Re: GTK frame changes,
Stephen J. Turnbull <=
- Re: GTK frame changes, Jan Djärv, 2009/07/03
- Re: GTK frame changes, Stephen J. Turnbull, 2009/07/03