Re: Standardizing _METACITY_UPDATE_COUNTER

[Soeren Sandmann <sandmann daimi au dk>]

gtg990h mail gatech edu writes:

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

How so? There is no additional complexity, just a slightly different
syntax. The basic protocol is exactly the same.

On the client side you just have to use XSyncSetCounter() instead of
XSendEvent(). In fact, XSetSyncCounter() is simpler to use than
XSendEvent().

On the WM side, things are the same, except that you should listen for
SyncAlarms instead of ClientMessages.

> That's fine if there is a good reason to use such a counter, I'm
> just trying to understand what that would be.

Without blocking the interaction will look basically like this:

        - WM sends SYNC_REQUEST
        - WM calls XMoveResizeWindow() 
 (1)    - WM draws new frame position
        - Client sees ConfigureNotify
        - Client layouts and draws
 (2)    - Client acknowledges ConfigureNotify
        - WM sees acknowledgement

Between (1) and (2) there will be a lag between application and frame
- not anywhere near as bad as the lag we see now, but still a lag.

With blocking, the interaction will look like this:

        - WM sends SYNC_REQUEST
        - WM sets the background of the frame window to None
        - WM calls XMoveResizeWindow()
        - On a separate X connection the WM
                - calls XSyncAwait()
                - paints the frame
        - Client sees ConfigureNotify 
(1)     - Client layouts and draws, and increments counter
(2)     - The counter increment unblocks the XsyncAwait() and 
          the frame is painted
        - WM sees acknowledgement

The lag between (1) and (2) would be essentially non-existing, at most
a brief flash, because it would be completely handled within the X
server.

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

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

Possibly, but I don't see any reason that is has to be handled by this
protocol. I think it is better to wait until the COMPOSITE extension
is better understood before trying to figure out what extra WM
protocols will be needed.

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

The one-to-one relationship is not necessary anymore. Now that we have
the serial numbers the WM can just use those to tell which of the
ConfigureNotifies the client has handled.

The WM should just make sure to send a _NET_SYNC_REQUEST before each
request (XMoveResizeWindow / synthetic ConfigureNotify) that will
generate a ConfigureNotify _that the WM wants acknowledged_. If the WM
decides that it doesn't need to get the synthetic ConfigureNotifies
acknowledged, it is perfectly fine for it to just not send
_NET_SYNC_REQUESTs before synthetic ConfigureNotifies.

As for the client, it should not care about synthetic vs. real
ConfigureNotifies. When it has seen SYNC_REQUEST it should just
acknowledge after fully handling at least one, but possibly more,
ConfigureNotifies, whether synthetic or not.


Søren