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: > >> >> 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. > > > Are you planning to test a specific alternate interval? > I don't know what Mike is planning to do exactly. > > 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. > > > Mine doesn't. Instead it slews the CPU clockspeed based on workload and > shuts down components (including the CPU) whenver possible. Get a Mac. :-) > In all seriousness, I see your point for Windows machines. User expectations > for the unplugged state may be lower. > Yeah, OK ;-) > > (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. -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev