Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller

On Mon, 2011-10-17 at 07:35 -0700, Arjan van de Ven wrote:

On 10/17/2011 7:28 AM, Peter Zijlstra wrote:

quoted

Or even when I minimize firefox. That said, ff will probably crash as 
soon as I open a second tab because the retarded thing will very 
likely continue animating everything on the invisible tab anyway. You 
could start by making the X lib of the day, is that XCB these days?, 
issue an error print (you get plenty of those anyway) and progress to 
full on crashing later. This gives developers a migration window and 
incentive to fix up their apps.

so back in the time that worked on a project that used Qt as their 
toolkit (geez is it that long ago already ;-) )... we fixed Qt to stop 
doing this.
The right level for this sort of thing is the toolkit level (which by 
and large also does the animations), not Xlib.
The toolkit level also will then need to provide the right notifications 
to the app for things the toolkit does not do
(eg "we're at least partially visible" versus "now none of our pixels 
are on the screen").

It ended up being a thing for the toolkit and a minor tweak in the 
compositor... and it worked quite ok, the app guys actually
asked for the API (because they knew I would beat them up for getting it 
wrong)...

doing things on the xlib level (or even X level) means you take away the 
chance for the App(tm) to do things the right way;
make it easy for the app, not hard.

I'm not immediately seeing how enforcing these semantics through X makes
it harder for the app, or would in fact get in the way of the toolkit
providing similar features.

But they key point to my argument is that at whatever level you're going
to do this, it needs to be unforgivingly enforced. Otherwise its useless
because people either don't know or don't care.

Esp. when you then go do crap like proposed and fudge the timers so that
the impact of doing it wrong is dampened.