On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >> >> On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: >> >> On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
