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

Peter Zijlstra
2011-10-17T14:45:56Z

On Mon, 2011-10-17 at 07:35 -0700, Arjan van de Ven wrote:
> On 10/17/2011 7:28 AM, Peter Zijlstra wrote:
> > 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.