[webkit-dev] setTimeout as browser speed throttle
darin at chromium.org
Thu Oct 2 22:09:18 PDT 2008
On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
> In short, our architecture makes me more willing to take risks with
>> setTimeout clamping than I would be otherwise. This is a good thing I think
>> because we have the opportunity to test this out and get more data without
>> risking as much.
> I guess I don't expect it to make a huge difference but if you would like
> to test a value higher than 1ms but less than 10ms in live code I'd
> certainly love to hear the results.
When we have that data, we'll share it. I'm not sure when that will happen.
> I think we just disagree here. In my opinion since setTimeout clamping is
>> so varied across browsers and even varies in Firefox depending on whether or
>> not a flash animation is going, the expectation of consistent clamping has
>> to be low. Or at least it has to be the case that it doesn't matter much if
>> different browsers have different clamping values in practice. So I think
>> there is room to do interesting things related to different power management
>> states. Anyways, I'm just telling you what we are considering doing.
> I'm not really talking about developer expectation here so much as the
> possibility that, if indeed a lower clamp is a performance improvement for
> real sites, then said sites would noticeably slow down the moment you
> unplug. As a user I would find that surprising and weird.
My laptop slows down considerably when I unplug it because of power saving
settings. I don't find that too unusual.
> (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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev