Re: Standardizing _METACITY_UPDATE_COUNTER

[gtg990h mail gatech edu]

sandmann daimi au dk writes: 
 
> I think the acknowledgement should be done through XSYNC, because I 
> don't think it is out of the question for a window manager to use 
> XSyncAwait() to block on the client's response (The WM would use a 
> separate connection to the X server to avoid stalls and deadlocking). 
I'm curious: how useful would it be for the wm to block on the response? Using 
XSync does make the implementation significantly more complex. That's fine if 
there is a good reason to use such a counter, I'm just trying to understand 
what that would be.  
 
> What is the use case for "No support"? I would suggest instead 
Absolutely none. However, the point of using an integer is that I wanted to 
keep it possible to define additional semantics, mainly for double-buffering. 
Depending on how we do double-buffering, you might need the client's 
cooperation.  
 
<snip> 
> This should say that 
>  
>         - The acknowledgement should happen after fully handling at 
>           least one, but possibly more, ConfigureNotify events 
>           (whether synthetic or not), where "fully handling" means 
>           having done all processing and drawing associated with the 
>           event. 
We should clarify what happens with synthetic ConfigureNotify events. To 
maintain the 1-1 relationship, the WM should send a _NET_SYNC_REQUEST for each 
synthetic ConfigureNotify event that it generates, as well as each real 
ConfigureNotify event that causes. Since the synthetic ConfigureNotify is not 
necessary during move/resize, we should add an implementation note advising WMs 
not to send a synthetic ConfigureNotify since a real-one will be generated. I 
want to avoid the situation with Tk that Lubos Lunak pointed out. 
 
<snip> 
> This looks fine, though it might not hurt to emphasize that the first 
> _NET_SYNC_REQUEST sent to a window should be 1, or at least non-zero 
> to distinguish a "virgin" counter. 
Good point.  
 
<snip> 
> These should just be implementation suggestions or in the 
> rationale. The point of the serial numbers is that the window manager 
> can have more than one outstanding _NET_SYNC_REQUEST at a time if it 
> wants to. 
Agreed. 
 
Sincerely, 
    Rayiner Hashem