On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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 is active. -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
