GTK frame changes

GTK frame changes

[grischka]

Jan Djärv <jan.h.d@swipnet.se> wrote in Changelog:

> xg_frame_set_char_size): Do not set pixel width/height here or
> call change_frame_size. Just call flush_and_sync.
> (flush_and_sync): Reintroduced.

Nice work and the idea is right IMO, just the problem remains that
"flush_and_sync()" does not guarantee that the resize request was
actually handled,  i.e. that a ConfigureNotify was received before
flush_and_sync() returns.  In my tests in ~70% of runs this is not
the case.

It might be somehow tricky to get there though. What it needs is
probably some modal event-loop that returns once ConfigureNotify has
arrived and in between handles other important events to make sure
it doesn't freeze.  It probably also needs some timeout, as for
example with resizing invisible (not-mapped) frames the ConfigureNotify
might never arrive.

There is a similar modal loop in emacs in the context of X selections
(in x_get_foreign_selection where it says TRACE1 ("  Start waiting %d
secs for SelectionNotify", secs).  So maybe there are some ideas or
code to copy from.  "secs" here may sound somewhat scary however in
the case of ConfigureNotify it should arrive really quickly. Just not
quickly enough that "flush_and_sync()" already sees it,

--- grischka

Re: GTK frame changes

[Jan Djärv]

grischka skrev:
> Jan Djärv <jan.h.d@swipnet.se> wrote in Changelog:
> 
>> xg_frame_set_char_size): Do not set pixel width/height here or
>> call change_frame_size. Just call flush_and_sync.
>> (flush_and_sync): Reintroduced.
> 
> Nice work and the idea is right IMO, just the problem remains that
> "flush_and_sync()" does not guarantee that the resize request was
> actually handled,  i.e. that a ConfigureNotify was received before
> flush_and_sync() returns.  In my tests in ~70% of runs this is not
> the case.

No, it is not certain.  But if the X server handles requests from clients in 
sequence (which it should), it is certain.  However, I haven't looked at the 
source of X servers to actually know this.

> 
> It might be somehow tricky to get there though. What it needs is
> probably some modal event-loop that returns once ConfigureNotify has
> arrived and in between handles other important events to make sure
> it doesn't freeze.  It probably also needs some timeout, as for
> example with resizing invisible (not-mapped) frames the ConfigureNotify
> might never arrive.
> 
> There is a similar modal loop in emacs in the context of X selections
> (in x_get_foreign_selection where it says TRACE1 ("  Start waiting %d
> secs for SelectionNotify", secs).  So maybe there are some ideas or
> code to copy from.  "secs" here may sound somewhat scary however in
> the case of ConfigureNotify it should arrive really quickly. Just not
> quickly enough that "flush_and_sync()" already sees it,
> 

Secs is scary indeed, as in the XMonad case, there will never be any 
ConfigureNotify, so it will not arrive quickly at all.  That is the problem.
So I made the simple solution.

	Jan D.

Re: GTK frame changes

[grischka]

Jan Djärv wrote:
> grischka skrev:
>> Jan Djärv <jan.h.d@swipnet.se> wrote in Changelog:
>>
>>> xg_frame_set_char_size): Do not set pixel width/height here or
>>> call change_frame_size. Just call flush_and_sync.
>>> (flush_and_sync): Reintroduced.
>>
>> Nice work and the idea is right IMO, just the problem remains that
>> "flush_and_sync()" does not guarantee that the resize request was
>> actually handled,  i.e. that a ConfigureNotify was received before
>> flush_and_sync() returns.  In my tests in ~70% of runs this is not
>> the case.
> 
> No, it is not certain.  But if the X server handles requests from 
> clients in sequence (which it should), it is certain.  

What makes you think that flush_and_sync would work if requests are
handled sequentially by the X server?

--- grischka

Re: GTK frame changes

[Jan Djärv]

grischka skrev:
> Jan Djärv wrote:
>> grischka skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> wrote in Changelog:
>>>
>>>> xg_frame_set_char_size): Do not set pixel width/height here or
>>>> call change_frame_size. Just call flush_and_sync.
>>>> (flush_and_sync): Reintroduced.
>>>
>>> Nice work and the idea is right IMO, just the problem remains that
>>> "flush_and_sync()" does not guarantee that the resize request was
>>> actually handled,  i.e. that a ConfigureNotify was received before
>>> flush_and_sync() returns.  In my tests in ~70% of runs this is not
>>> the case.
>>
>> No, it is not certain.  But if the X server handles requests from 
>> clients in sequence (which it should), it is certain.  
> 
> What makes you think that flush_and_sync would work if requests are
> handled sequentially by the X server?
> 

XSync sends a request to the server and waits for a reply.  The resize request 
is sent before that, so the resize should be handeled before the XSync reply 
is sent.

	Jan D.

Re: GTK frame changes

[grischka]

Jan Djärv wrote:
> 
> 
> grischka skrev:
>> Jan Djärv wrote:
>>> grischka skrev:
>>>> Jan Djärv <jan.h.d@swipnet.se> wrote in Changelog:
>>>>
>>>>> xg_frame_set_char_size): Do not set pixel width/height here or
>>>>> call change_frame_size. Just call flush_and_sync.
>>>>> (flush_and_sync): Reintroduced.
>>>>
>>>> Nice work and the idea is right IMO, just the problem remains that
>>>> "flush_and_sync()" does not guarantee that the resize request was
>>>> actually handled,  i.e. that a ConfigureNotify was received before
>>>> flush_and_sync() returns.  In my tests in ~70% of runs this is not
>>>> the case.
>>>
>>> No, it is not certain.  But if the X server handles requests from 
>>> clients in sequence (which it should), it is certain.  
>>
>> What makes you think that flush_and_sync would work if requests are
>> handled sequentially by the X server?
>>
> 
> XSync sends a request to the server and waits for a reply.  The resize
> request is sent before that, so the resize should be handeled before the 
> XSync reply is sent.

Yes, but this reply is something in the sense of the X protocol, not
in the sense of ConfigureNotify.  It just means that the X server got
the resize message when XSync returns.   It doesn't mean at all that
a ConfigureNotify is already in the client queue let alone that emacs
now knows how big it is.

--- grischka

> 
>     Jan D.
> 

Re: GTK frame changes

[Jan Djärv]

grischka skrev:
> Jan Djärv wrote:
>> XSync sends a request to the server and waits for a reply.  The resize
>> request is sent before that, so the resize should be handeled before 
>> the XSync reply is sent.
> 
> Yes, but this reply is something in the sense of the X protocol, not
> in the sense of ConfigureNotify.  It just means that the X server got
> the resize message when XSync returns.   It doesn't mean at all that
> a ConfigureNotify is already in the client queue let alone that emacs
> now knows how big it is.
> 

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).
The execution of a request includes validating all arguments,
collecting all data for any reply,
and generating and queueing all required events.
However, it does not include the actual transmission of the reply and the events.
In addition, the effect of any other cause that can generate multiple events
(for example, activation of a grab or pointer motion) must effectively 
generate and queue all required events indivisibly with respect to all other 
causes and requests.
For a request from a given client,
any events destined for that client that are caused by executing the request
must be sent to the client before any reply or error is sent."

I interpret this as for a given X connection, all requests are run to 
completion and replies and events are queued in order.  Since XSync waits for 
the reply, it also means that after XSync has returned, events and replies 
generated by previous requests have indeed arrived.

	Jan D.

Re: GTK frame changes

[grischka]

Jan Djärv wrote:
> grischka skrev:
>> Jan Djärv wrote:
>>> XSync sends a request to the server and waits for a reply.  The resize
>>> request is sent before that, so the resize should be handeled before 
>>> the XSync reply is sent.
>>
>> Yes, but this reply is something in the sense of the X protocol, not
>> in the sense of ConfigureNotify.  It just means that the X server got
>> the resize message when XSync returns.   It doesn't mean at all that
>> a ConfigureNotify is already in the client queue let alone that emacs
>> now knows how big it is.
>>
> 
> 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).
> The execution of a request includes validating all arguments,
> collecting all data for any reply,
> and generating and queueing all required events.
> However, it does not include the actual transmission of the reply and 
> the events.
> In addition, the effect of any other cause that can generate multiple 
> events
> (for example, activation of a grab or pointer motion) must effectively 
> generate and queue all required events indivisibly with respect to all 
> other causes and requests.
> 
> For a request from a given client,
> any events destined for that client that are caused by executing the 
> request
> must be sent to the client before any reply or error is sent."

I'm somehow confused what they mean by reply here.  If events are sent
before replies then replies must be something else.

> I interpret this as for a given X connection, all requests are run to 
> completion and replies and events are queued in order.  Since XSync 
> waits for the reply, it also means that after XSync has returned, events 
> and replies generated by previous requests have indeed arrived.

Okay, I tested once more with an undecorated window and there indeed it
looks like your interpretation might be right.

Just with WM redirection (metacity here) the ConfigureNotify clearly arrives
about 2 ms later and the behavior is completely unimpressed by XSync.

--- grischka

>     Jan D.
> 

Re: GTK frame changes

[Jan Djärv]

grischka skrev:
> Jan Djärv wrote:
>> grischka skrev:
>>> Jan Djärv wrote:
>>>> XSync sends a request to the server and waits for a reply.  The resize
>>>> request is sent before that, so the resize should be handeled before 
>>>> the XSync reply is sent.
>>>
>>> Yes, but this reply is something in the sense of the X protocol, not
>>> in the sense of ConfigureNotify.  It just means that the X server got
>>> the resize message when XSync returns.   It doesn't mean at all that
>>> a ConfigureNotify is already in the client queue let alone that emacs
>>> now knows how big it is.
>>>
>>
>> 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).
>> The execution of a request includes validating all arguments,
>> collecting all data for any reply,
>> and generating and queueing all required events.
>> However, it does not include the actual transmission of the reply and 
>> the events.
>> In addition, the effect of any other cause that can generate multiple 
>> events
>> (for example, activation of a grab or pointer motion) must effectively 
>> generate and queue all required events indivisibly with respect to all 
>> other causes and requests.
>>
>> For a request from a given client,
>> any events destined for that client that are caused by executing the 
>> request
>> must be sent to the client before any reply or error is sent."
> 
> I'm somehow confused what they mean by reply here.  If events are sent
> before replies then replies must be something else.

Some X requests have replies from the server (like XCreatePixmap, the reply 
contains the Pixmap id), some don't (like XFreePixmap).

> 
>> I interpret this as for a given X connection, all requests are run to 
>> completion and replies and events are queued in order.  Since XSync 
>> waits for the reply, it also means that after XSync has returned, 
>> events and replies generated by previous requests have indeed arrived.
> 
> Okay, I tested once more with an undecorated window and there indeed it
> looks like your interpretation might be right.
> 
> Just with WM redirection (metacity here) the ConfigureNotify clearly 
> arrives
> about 2 ms later and the behavior is completely unimpressed by XSync.
> 

With redirections all bets are off, since the X server can't know when or if 
there will be a reply.

	Jan D.

Re: GTK frame changes

[Stephen J. Turnbull]

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.

Re: GTK frame changes

[Jan Djärv]

Stephen J. Turnbull skrev:
> 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.
> 

Not missing, just ignoring ...


> 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.

And also the WM may choose to alter or drop that request.  Which is why
Lisp code that sets a frame size and immediately after expect that frame
to have that size is no good.  The sync-thingy is just an optimization so that 
lisp code will see its expected size as fast as we can make it happen, in the 
cases the WM does honor the size request.


> "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.

Agreed.

	Jan D.

Re: GTK frame changes

[Stephen J. Turnbull]

Stephen J. Turnbull writes:

 > Jan is missing a number of issues, I think.

Apparently Jan had the necessary clues, it was just the post that was
missing explicit discussion of them, that's all.  Sorry, Jan!