HI Maciej,
On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote:
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.
I agree with that. To me burying a tab is an explicit and often
deliberate user gesture. It would take novice users little time to
adjust to the pausing of buried tabs (pausing with respect to all
processing: plugins, animated images, and javascript for example). If
audio is playing and it pauses because the tab is buried, the user
will quickly come to understand that the tab needs to be exposed and
to switch to a new window to create the new tab. The audio still plays
in a background window, just not in a background tab. Until tab
management gets up to speed, that would be a prudent approach anyway.
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.
My experience is that the problem is much more of a problem (but I'm
mobile a lot). Adding a new highres timer is a good step, but if
that's already available, then providing setTimeout a 15 fold
difference in clamps between WebKit and IE (the primary test browser)
will really exacerbate the problem (perhaps as much as a significant
percentage loss in battery-charge-life).
As for trying to avoid restricting timers that merely leads to
restricting javascript in total. The only reason I would ever want to
turn off javascript is to control poorly authored timers (and similar
poorly authored plugins and plugin authoring). So I lose all
javascript support simply to avoid timers, where I would prefer to
lose the timer capabilities and still have the remaining javascript or
maintain all javascript and lose timers for buried tabs.
If we assume the new highres API will not be abused the way setTimeout
is abused (and that my require other event APIs as well such as a
convenience method setting the interval by a specific date-time rather
than only by interval), then I think there is even more reason to
enable users to constrain the abuse of setTimeout (and plugins)
specifically.
Take care,
Rob
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
