Re: Standardizing _METACITY_UPDATE_COUNTER

[Soeren Sandmann <sandmann daimi au dk>]

gtg990h mail gatech edu writes:

> Okay, let me try to specify this somewhat more formally. I understand, after 
> Soeren Sandmann's last message, why it makes sense to let the client increment 
> the counter by more than one for each resize step. I also think I understand 
> Owen Taylor's concern about being able to keep track of the client's location 
> in the update stream. Further, making the protocol two-way might make it easier 
> to double-buffer, depending on how double-buffering is done.  
>  
> I tried to follow the formatting of the wm-spec, to make things easier to 
> understand: 

It generally looks sensible, but I do have some comments:

> _NET_SYNC_REQUEST (client message)  
>     window = top-level window being resized 
>     message_type = _NET_SYNC_REQUEST  
>     format = 32  
>     data.l[0] = low-bits of counter value  
>     data.l[1] = high-bits of counter value  

Looks fine.

> _NET_SYNC_ACKNOWLEDGE (client message)  
>     window = top-level window being resized 
>     message_type = _NET_SYNC_ACKNOWLEDGE  
>     format = 32  
>     data.l[0] = low-bits of counter value  
>     data.l[1] = high-bits of counter value  

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

> _NET_WM_SYNC_SUPPORT (client window property)  
>     Integer specifying level of support for synchronization.  
>     - 0: No support  
>     - 1: Synchronization during resize  

What is the use case for "No support"? I would suggest instead

_NET_WM_SYNC_COUNTER (client window property)

      XID specifying a SYNC counter used for acknowledging
      ConfigureNotify events. It is considered an error to set the
      property to None. The existance of this property indicates that
      the client is willing to participate in the protocol.

If there really is a use for "No support", then None could be
acceptable for the XID and mean "No support".

> Client behavior:  
>     At startup, set the _NET_WM_SYNC_SUPPORT property to indicate support for 
>     synchronization. 

      At startup, create a new SYNC counter and set the
      _NET_WM_SYNC_COUNTER property to the counter's XID. The counter
      must be initialized to 0.

>     On receiving _NET_SYNC_REQUEST, set internal flag specifying that the next 
>     ConfigureNotify event should be acknowledged with a _NET_SYNC_ACKNOWLEDGE 
>     client message.  
>       
>     On receiving ConfigureNotify, compress any number of ConfigureNotify and 
>     Expose events in queue. Handle all drawing resulting from those events. 
>     Send the window manager a _NET_SYNC_ACKNOWLEDGE client message with the 
>     counter set to the value specified in the latest
>     _NET_SYNC_REQUEST message.  

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.

        - The acknowledgement should be done by using
          XSyncSetCounter() to set the counter to the value specified
          in the latest _NET_SYNC_REQUEST message.

        - That it is permissible for the client to compress several
          _NET_SYNC_REQUEST messages and only acknowledge the last
          one. 

> Window manager behavior:  
>     During resize, send _NET_SYNC_REQUEST before calling XMoveResizeWindow.  
>     The counter value specified in the message should be 1 + the number of 
>     NET_SYNC_REQUEST messages the window manager has sent so far to the  
>     client window. 

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.

>     Do not send another _NET_SYNC_REQUEST, or call 
>     XMoveResizeWindow until either a timeout expires, or a     
>     _NET_SYNC_ACKNOWLEDGE is received.  
>       
>     If the resize timeout expires, send another _NET_SYNC_REQUEST followed by 
>     calling XMoveResizeWindow.  

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.


Søren