idle detection
Sean Egan
seanegan at gmail.com
Thu Aug 2 03:43:02 EDT 2007
On 8/1/07, Richard Laager <rlaager at wiktel.com> wrote:
> Unless you've changed the code or there's a bug (such as the hardcoded
> IDLEMARK vs. the pref), we poll at the point where the logic will
> register a change. For example, if you're supposed to go away after
> being idle for 10 minutes and you've been idle for 2 minutes, we'll
> check again in 8 minutes.
Right, I should have been clearer. In any case, I think we agree that
the going-to-idle case could not be made more efficient.
> I don't see why you need to have this detected instantly.
Sure. What was I thinking?
While we're at it, let's introduce a random timeout between setting
your status message and sending it to the server. When Pidgin starts,
let's take our time logging in... perhaps offer the user a Sudoku
puzzle to pass the time.
I'm teasing, obviously, but there should be no latency between when a
user's state changes and when we report that change. If I were ever to
experience a one minute latency in anything that was supposed to
detect my use of the keyboard and mouse, I would without doubt
consider that a major bug.
I think the power-saving idle changes are great, and very important,
but they affect very few users in a very minor way. If someone were to
do an experiment: run Pidgin once, on a 2.6.21 or later kernel,
polling idle time every minute and then once every 3 seconds, and see
how that affected battery life, and the frequency showed an actual,
significant difference, I might concede.
Even then, we're already waking up every 30 seconds with
purple_timeout_add_seconds to send our keepalive packets, and I know
that I, at least, am receiving IM packets more frequently than that.
If we're going to be concerned about saving power by keeping our
process asleep for as long stretches as possible, we need to do a lot
more than just change the xserver polling time.
Without proof that polling as frequently as reasonable is harmful, I'm
not willing to hurt the user experience, especially when the feature
can be simply turned off.
-s.
More information about the Devel
mailing list