Martin Graesslin wrote:
> I don't really understand. How can it signal too early?
I was wrong about the MS Windows implementation, but from WidgetBasedPoller:
Q_FOREACH(int timeOut, m_timeouts) {
if ( ( timeOut - idle < 300 && timeOut >= idle ) || ( idle - timeOut <
300 && idle > timeOut ) ) {
// Bingo!
emit timeoutReached( timeOut );
}
}
that code accepts any idle value that is within ±300ms of timeOut. Since idle
increases monotonically after onset, and if comparisons are done often enough,
the code will signal up to 300ms early.
> I can say for Wayland as I wrote that recently:
I'm guessing Wayland will provide a mechanism that's inspired by what Xcb
provides?
> * it will fire if it's hit - there might be a delay which I think doesn't
> matter in the case of being swapped out.
Do you mean that the delay is independent of whether or not you're swapped out,
or that the question of how long the delay is is moot if you are (were) swapped
out? It will "Fire if it's hit", but what "it" doesn't get hit at the
configured
time but at a later time?
> The Wayland implementation doesn't give a guarantee that if there is an idle
> time of 5 sec it will be signalled exactly after 5 sec. That's something a
> non-realtime system cannot provide.
Of course not. But that doesn't mean it is pointless to try to minimise the
delay (for instance by polling ;))
To put this into perspective: the last thing I wrote in this context was an
extension to Matlab/Simulink that allowed to run a compiled Simulink model
realtime on a sufficiently fast host, without need for special realtime
hardware.
Let's be clear about this: true realtime indeed requires a special system, or
at
the very least support from the OS, and the appropriate coding approach in your
own application. I have a hunch that Qt is already used "that way" (it exists
on
Qnx after all). There aren't that many applications that need 100%, "hard"
realtime behaviour (as opposed to only a fraction of their running time).
Realtime also isn't necessarily about the lowest possible delays (they just
need
to be known and more or less constant). OTOH there are many more types of
applications that want to be perceived to run in real time, with the smallest
possible delays. IMHO those kind of applications (games, simulators,
psychophysics or other empirical software, ...) are much more likely to resort
to convenience frameworks like those provided by KF5.
(I was going to add "apps for controlling little trains" but those probably
have
little need for KIdleTime, just for other time-related functions with
comparable
"good" behaviour :))
> And honestly I don't think it matters. KIdleTime is about being noticed about
> being idle. We are talking here about timeouts which are in an area where
> realtime doesn't matter [...]
> If you want
> to use KIdleTime for anything below let's say half a minute, I think it's the
> wrong tool for it.
And I really don't see the point in providing a framework for this (and
basically only this) if it's not going to try to be as versatile as possible.
It
can and should aim to avoid hogging any resources in the default configuration.
But as it happens it is actually more complicated to implement that than to
implement the basic approach that can also provide the best precision and
detection delays. I think the framework becomes more versatile if it allows
users to switch it to a more precise/powerful and (possibly) more intrusive
mode.
If of course the majority of major platforms on which it is deployed support
the
kind of precision I'm thinking of.
BTW, the exact durations are inconsequential (as long as they're above what can
be timed a reasonable precision). It's not because you're interested to learn
if
an application has been idle for 10min that all of a sudden it becomes more
acceptable to detect that with a much worse precision.
And FWIW: any backend that's based on QTimer and use Qt::PreciseTimer to
achieve
better than 5% error (= at least ms accuracy).
R.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
