Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

[Dario Freddi]

Given I already stepped in...

2015-11-19 10:36 GMT+01:00 René J.V. <rjvbertin at gmail.com>:
>
> Now it's just bad code, eh?
>
> Just for the record: no one but Apple really knows what IOKit considers being idle but it clearly involves absence of user input events. That's "user idle", not "system idle" (term from the KIdleTime docs!), and how long of the former you need to attain the latter (or something you consider "system idle") is completely up to the software to decide. Because it involves event timing, this can be determined with as much precision as native events can be timed (and if I'm not mistaken those are accurate enough to support a 1ms resolution on OS X).
>
> I'm not going to repeat my position on polling or on how it's up to the user to decide whether or not idle timeout detection is too expensive.
> As long as people here remain dead-set against anything the uses it without even testing the actual implementation, then I am not going to reconsider contributing to this code. Writing great software doesn't necessarily mean applying all applicable principles without wiggle room (and I'd hope that's about the only thing I'm dogmatic about myself :)).
>
> Apparently I might want to reconsider using QTimer, though, there might be more accurate and/or less intrusive mechanisms available natively - and now that I incorporated some ObjC it ought to be a lot less work to experiment with those.

René, Martin was just questioning your choice of Qt::PreciseTimer. From Qt docs:

For Qt::CoarseTimer, the interval will be adjusted up to 5% to align
the timer with other timers that are expected to fire at or around the
same time. The objective is to make most timers wake up at the same
time, thereby reducing CPU wakeups and power consumption.

Which is *exactly* the purpose of KIdleTime - notifying with a relaxed
precision (because let's face it, as Martin already explained the
added precision value is completely pointless if we're talking about
**user** activity) with the minimum consumption of system resources.
And this is exactly what :CoarseTimer does. So I stand behind Martin's
comment and agree with it. It does not relate to IOKit or anything
else, but just with the purpose for which you're using QTimer in that
context. And note that people here are not dead-set without concrete
and actual reason: the new Qt5 API of QTimer was designed with these
kind of use cases in mind. The fact that (of course) you don't notice
any concrete difference might change when you scale back to a more
constrained system - and it's the purpose of frameworks to be as
efficient as possible everywhere. And most of all, there's no gain in
using PreciseTimer at all here - actually KIdleTime might even use
VeryCoarse. That's all.

In the bigger scheme: would you be happy to know that your laptop is
consuming more energy just to know more accurately when it's a good
time to suspend to save energy? :)

P.S.: On you reconsidering QTimer: the fact you might be using a
different API won't change the base problem, which you will face
anyway: having a precise timer implies consuming more resources and
having more wakeups.