On Mon, Oct 17, 2011 at 04:49:29PM +0200, Peter Zijlstra wrote: > On Mon, 2011-10-17 at 15:40 +0100, Matthew Garrett wrote: > > On Mon, Oct 17, 2011 at 04:28:27PM +0200, Peter Zijlstra wrote: > > > An XDamage and repaint from the X client, after which your copy will > > > complete and you get what you asked for? > > > > An XDamage and then an asynchronous RPC call to the remote server to > > identify the contents of the next frame before drawing them, plus some > > sort of new synchronisation mechanism for blocking the X query until > > that point? > > Why would this be a problem? > > I mean, why would getting a copy of an otherwise invisible surface be a > performance sensitive path? If the compositor needs the surface it would > make it visible and send the XDamage once and keep it visible henceforth > until the time it again becomes invisible, at which point you have to > stop updates again. I'm not saying that it's a problem. I'm saying that your approach changes behavioural semantics in a way that may violate application expectations just as surely as changing the timer behaviour does. There's no free approach. > > Timers are a resource. People want to manage that resource. cgroups are > > a convenient mechanism for managing resources. > > Yes, and a ball is round (unless you're a USA-ian, in which case they're > ovoid), what's your point? If there's no reason to want to manage that resource, why do we support timer slack at all? -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
