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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
