[webkit-dev] setTimeout as browser speed throttle

[Darin Fisher]

On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns <robburns1 at mac.com> wrote:

> Hi Darin,
> On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
>
> On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
>>
>> On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>>
>>>  (I don't understand your comment about not having to have it on all the
>>>> time.  Surely if a page is asking for a fast setTimeout repeatedly, it would
>>>> be on "all the time.")
>>>>
>>>
>>> My understanding is that timeBeinPeriod(1) is currently on all the time
>>> in Chrome, even when no short-delay timers are currently pending, thus
>>> leading to constant greater power consumption. But there is no need for it
>>> to be on when there are not fast timers pending. See
>>> WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically
>>> better approach than switching based on power management state. Feedback
>>> welcome, though, and perhaps you will still come to a different conclusion.
>>
>>
>> I think that is a good idea too, but it doesn't help when a fast
>> setInterval is active.
>>
>>
>> That is true. With the webkit.org version of SharedTimerWin, though, you
>> can at least close the problematic tab when you hear your fan spin up and
>> stop suffering any power drain. It may be that running slower is a better
>> option.
>>
>
>
> Yeah, that's the trade off.  Close the offending tab or let it run, but
> more slowly.
>
>
> Another option, would be to halt timers for all unexposed tabs (i.e., tabs
> in windows that are not the frontmost tab). Are there use-cases or sites
> that would break with such behavior? The reason I raise this option is that
> the loaded page represents important state to the user, but when it is
> buried on a window, it is probably not necessary for it to be actively
> responding to timer callbacks. Closing the tab saves battery life, but
> burying the tab behind another tab would be preferable for the user (a
> mobile user that may not be online when that important state represented by
> the page loaded in the tab is sought again).
>
> Take care,
> Rob
>


It's a good question.  I suspect though that it could break sites.  Imagine
a calendar application that wishes to periodically wake up to see if it
should put up an alert to notify you of an upcoming event.  Such a feature
probably requires the ability to run a timer.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/a3c45656/attachment.html