Re: KIdleTime : provide a settable resolution for the polling backends?
On Tuesday, November 17, 2015 8:42:31 AM CET Martin Graesslin wrote: > On Monday, November 16, 2015 1:31:02 PM CET René J.V. Bertin wrote: > > Hi, > > > > Working on modernising the OS X plugin for KIdleTime, I realised that > > there > > is no mechanism foreseen to set the frequency at which the current system > > idle time should be sampled on those platforms that need to use a polling > > approach (OS X, MS Windows and apparently also XScreenSaver). > > Maybe you see something which I do not: where does XScreenSaver use polling? Ah found it. It's in the parent WidgetBasedPoller. I think that implementation already answers how you should do the polling, because it has an implementation for it. But nevertheless: please try to not poll. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KIdleTime : provide a settable resolution for the polling backends?
On Monday, November 16, 2015 1:31:02 PM CET René J.V. Bertin wrote: > Hi, > > Working on modernising the OS X plugin for KIdleTime, I realised that there > is no mechanism foreseen to set the frequency at which the current system > idle time should be sampled on those platforms that need to use a polling > approach (OS X, MS Windows and apparently also XScreenSaver). Maybe you see something which I do not: where does XScreenSaver use polling? > > The frequency with which idle time is polled (sampled) determines the delay > with which the resumingFromIdle signal can be sent, but also the precision > of the timeoutReached signals. > > At the moment I'm using a QTimer interval of 0 to poll idle time, meaning > the timer fires and idletime is fired about as fast as possible when there > are no events to process. That is fine for a system that wants to react as > fast as possible to the end of an idle period, but probably overkill in > many other situations. It strikes me that the required resolution is > something that only the calling code can know, though there are probably > several values that are reasonable defaults (10x per second seems a bit > much, 4x maybe just too low). > > Thoughts? Don't poll. Never ever, don't poll. That's the opposite of what an application wants to do. The application wants to sleep till there is an event where it should do something. Keeping the application in a busy loop is the exact opposite So don't poll. I know that is easy said, but in the end I think it's better to not provide the feature than to perform polling. I don't see a problem with a specific feature not being available. Consider for example my implementation for Wayland (in kwayland-integration). I had the complete control over the platform, but decided not to add support for supporting the forcePollRequest. Please find a solution which doesn't use polling. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KIdleTime : provide a settable resolution for the polling backends?
Aleix Pol wrote: > I guess it's because it shouldn't poll necessarily, but get a > notification whenever the OS considers appropriate. Polling is > considered a bad practice in general. I'd agree, but not all OSes provide other mechanisms, in which case polling is the only remaining option. Reason the more to allow the polling load to be tuned to requirements if you ask me. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KIdleTime : provide a settable resolution for the polling backends?
On Mon, Nov 16, 2015 at 10:31 PM, René J.V. wrote: > Hi, > > Working on modernising the OS X plugin for KIdleTime, I realised that there > is no mechanism foreseen to set the frequency at which the current system > idle time should be sampled on those platforms that need to use a polling > approach (OS X, MS Windows and apparently also XScreenSaver). > > The frequency with which idle time is polled (sampled) determines the delay > with which the resumingFromIdle signal can be sent, but also the precision of > the timeoutReached signals. > > At the moment I'm using a QTimer interval of 0 to poll idle time, meaning the > timer fires and idletime is fired about as fast as possible when there are no > events to process. That is fine for a system that wants to react as fast as > possible to the end of an idle period, but probably overkill in many other > situations. It strikes me that the required resolution is something that only > the calling code can know, though there are probably several values that are > reasonable defaults (10x per second seems a bit much, 4x maybe just too low). > > Thoughts? > > R. I guess it's because it shouldn't poll necessarily, but get a notification whenever the OS considers appropriate. Polling is considered a bad practice in general. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
