[webkit-dev] setTimeout as browser speed throttle
darin at chromium.org
Fri Oct 3 03:22:47 PDT 2008
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
> 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,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev