Quoting Soeren Sandmann <sandmann daimi au dk>: 
> How so? There is no additional complexity, just a slightly different 
> syntax. The basic protocol is exactly the same. 
I was talking more about the complexity of the implementation. I was reviewing 
the patches, and not using XSync would cut the size of the patches by a third 
to a half. Anyway, I see that there is an advantage to using XSync, so I'm okay 
with the extra implementation complexity. 
> Of course, this blocking algorithm _is_ much more complex than the 
> simple non-blocking one, but since doing the replies through the SYNC 
> extension isn't really any more complex than sending client messages, 
> I don't see any reason to not make it _possible_. 
Okay. I'm going to try to implement the blocking algorithm in kwin to see just 
how much more complex it is :)  
Anyway, I agree with the comments you made, so here is the revised protocol: 
_NET_SYNC_REQUEST (client message)   
    window = top-level window being resized or moved 
    message_type = _NET_SYNC_REQUEST   
    format = 32   
    data.l[0] = low-bits of counter value   
    data.l[1] = high-bits of counter value   
_NET_WM_SYNC_COUNTER (client window property) 
    type: XA_CARDINAL 
    format: 32 
    nelements: 1 
    XID of a SYNC extension counter associated with the client window.  
    The presence of this property, set to a value that is not None,  
    indicates the willingness of the client to participate in this protocol. 
Client window behavior:   
    At startup, create a new SYNC counter object, initialized to 0.Set the   
    _NET_WM_SYNC_COUNTER window property to the XID of this counter. 
    On receiving a _NET_SYNC_REQUEST, note that the next ConfigureNotify  
    must be acknowledged.  
    On receiving a ConfigureNotify for which a _NET_SYNC_REQUEST is pending,  
    first complete all processing and drawing associated with the event. 
    Then, acknowledge the _NET_SYNC_REQUEST by setting the SYNC counter to  
    the value specified in the request. 
    It is permissable to compress acknowledgements to _NET_SYNC_REQUEST  
    messages by setting the SYNC counter to the value specified in the  
    latest handled message. 
Window manager behavior:   
    When performing a window operation where synchronization is desired,  
    send a _NET_SYNC_REQUEST to the client before sending a synthetic      
    ConfigureNotify event, or causing a real one to be generated by calling   
    When sending a _NET_SYNC_REQUEST, set its counter value to a serial  
    number. This number should start at 1 and increase by 1 for each  
    _NET_SYNC_REQUEST sent to a given client window. 
Implementation notes: 
    When resizing or moving a window, a window manager is advised to not  
    perform another XMoveResizeWindow, and not send the associated 
    _NET_SYNC_REQUEST until the client has acknowledged the previous request. 
    Window managers are advised to implement a timeout on how long they will 
    wait for a client to acknowledge a _NET_SYNC_REQUEST. After this timeout 
    expires, window managers are allowed to send another _NET_SYNC_REQUEST, 
    and perform another XMoveResizeWindow. 
    Rayiner Hashem  

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]