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:
quoted
On Mon, Oct 17, 2011 at 04:28:27PM +0200, Peter Zijlstra wrote:
quoted
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.
quoted
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-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org