On Oct 3, 2008, at 3:10 AM, Rob Burns 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).
There are web apps that a user may legitimately want to continue to
work in the background. One obvious example is a web-based audio
player, although in that case it would be a plugin or <audio> element
continuing to do work. Still, if you're going to allow plugins and
media elements to continue, you may as well allow timers. Other sites
update their title on a timer in a way that is useful for a background
tab. For example, GMail updates the unread count, which is quite
useful on a background tab label. Given these kinds of examples, I
think pausing anything in a background tab would not be a good choice;
if that kind of functionality were on offer it should be a more
explicit user gesture.
All in all, I think we shouldn't overreact on the timer issue. Sites
that consume egregious amounts of computing resources, whether through
timers or otherwise, are the minority, and so long as they suck in all
browsers and not just some, users will blame the site and it will be
pressured to change. So really (in my opinion), matching or beating
the CPU consumption of other browsers is the target, and we shouldn't
go crazy with novel ways to restrict timers or anything else. Just
avoid looking broken on sites that were only tested in IE or Firefox.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
