On Mon, 2011-10-17 at 15:11 +0100, Matthew Garrett wrote:
On Mon, Oct 17, 2011 at 03:06:26PM +0200, Peter Zijlstra wrote:
quoted
On Mon, 2011-10-17 at 13:46 +0100, Matthew Garrett wrote:
quoted
They're orthogonal. Sometimes you want timer-driven behaviour (how else
are you going to draw animations?) and that's obviously going to
generate wakeups. This is for the idle case, where the user is no longer
sitting in front of the machine but you don't want to trigger a full
system suspend. We either need every application that ever uses
timer-driven behaviour to support setting its own timer slack on some
sort of external policy decision, or we need a way to let the kernel
force them to.
No!! you want that application to stop drawing stuff that is invisible.
Setting your own timerslack for something you know is pointless is worse
than doing something pointless, its down right stupid.
Whether or not you want the animation to carry on animating is policy,
and you need something to be the policy agent. Let's say firefox is
invisible. I now grab a copy of its window contents. What do I get?
An XDamage and repaint from the X client, after which your copy will
complete and you get what you asked for?
quoted
Please, work with the X folks and make it an error to draw to invisible
surfaces. And yes, I know that composition makes that a non-trivial
problem. But at least the blank screen case should be trivial, and I
suspect there's more tractable cases as well. Mostly the desktop is
still a very static place and a few extra timer ticks for when you're
spinning your desktop cube around isn't going to be a problem.
So, just to be clear on this, you want to change the semantics of X and
modify every piece of userspace that currently uses X (because it'll now
otherwise crash when the screen blanks)
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.
in preference to merging a piece
of code that's functionally consistent with the rest of the cgroups
infrastructure?
Yep.. because as of yet there isn't a sane use-case to warrant adding
the maintenance burden. Any cgroup controller is functionally
consistent, per definition, that doesn't make it useful or even sane.