KIdleTime: early and/or failing/rejected timeout detection?

Aleix Pol aleixpol at kde.org
Wed Nov 18 14:33:06 UTC 2015


On Wed, Nov 18, 2015 at 12:33 PM, René J. V. <rjvbertin at gmail.com> wrote:
> Actually, there is one thing I may have missed in the documentation, if it's
> there:
>
> Is KIdleTime supposed to detect system idling, or application idling? As it
> happens, it should be possible to make a distinction between the two with the
> latest implementation I made.
>
> As to using an agent to centralise all polling: I think that agent would either
> have to use poll timer with a sufficiently short interval to serve all clients,
> or use a poll timer per current client. Evidently the latter option cancels any
> benefit of moving to an agent-based architecture (leaving only the IPC
> overhead), while the former will lead to worse overhead than what my current
> implementation allows.
> That current implementation is not expensive in its default configuration (and
> that configuration is currently decided at build time), but I think that good
> programming practice would call anyway for deactivating any KIdleTime instances
> when they are not in use, regardless of whether they're based on alarms or on
> polling.
>
> I have no idea how many applications will be using this framework concurrently
> at any given time, but it seems reasonable to expect that there will be less
> than on a system running a KF5 plasma desktop. I see it's used in Baloo, for
> instance, but that framework has dropped support for OS X.
>
> There's also always the possibility to reconsider implementing an Xcb-style
> alarm based mechanism that relies on a helper process, if it turns out in the
> future that KIdleTime/Mac is causing significant amounts of overhead. But
> KIdleTime has changed only minimally from KDE4 to KF5, and it is certainly not
> the case that it has led to any observable amount of continuous overhead until
> now.
>
> R

After a quick search, here's some relevant documentation by Apple:
https://developer.apple.com/library/mac/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/

They suggest you going "App Nap" as soon as possible. Polling from a
framework would ensure this doesn't really happen.

Here's an approach that could maybe inspire you somehow:
http://stackoverflow.com/questions/1419531/mac-screensaver-start-event

Aleix


More information about the Kde-frameworks-devel mailing list