Re: Standardizing _METACITY_UPDATE_COUNTER

[gtg990h mail gatech edu]

Quoting Havoc Pennington <hp redhat com>:  
   
 > On Sat, 2004-02-21 at 15:20, Lubos Lunak wrote:  
 > >  Hmm. Could somebody please explain to me why this actually has to use  
 > XSYNC   
 > > counter? I might be wrong, but it seems to me that the KWin patch actually  
 >   
 > > doesn't check the value of the counter, it simply stops the timeout and  
 > does   
 > > another move/resize when it gets notification about counter update. I   
 > > remember I wondered a bit about this, but it makes sense to me:  
 >   
 > The main feature XSync adds is the ability to block on the counter -  
 > something window managers probably don't want to do. I guess you can  
 > also with XSync say "add one to counter" instead of just "set property  
 > to N", but as we're ignoring the values and only the client updates this  
 > is probably not useful. Another hypothetical advantage of XSync counters  
 > is that they can be bound to vertical retrace and other such things.  
   
 The reason I used XSYNC was because you used it :) IMHO, there are a couple of  
 advantages to using XSYNC anyway:  
   
 - It seems to be a cleaner and more task-appropriate way of handling this. The  
 XSYNC API was basically designed to handle this sort of thing. Of course, if  
 you want two-way communication then you whould have to use something else...  
   
 - XSyncSetPriority() has the potential to be useful. Giving a temporary  
 priority boost to the currently resizing app while waiting for updates makes  
 resizing look better for very complex apps. Currently, the kwin code has that  
 usage disabled, because it totally starves apps under the currently-resizing  
 window, but perhaps when we get double-buffered windows it'll become useful  
 again.