[webkit-dev] High Resolution Timer API proposal(s)

[Rob Burns]

Hi Peter,

On Oct 3, 2008, at 8:36 PM, Peter Kasting wrote:

> On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood  
> <jhaygood at reaktix.com> wrote:
> I'd say define it as a minimum precision of 1ms, but browser  
> manufacturers can define any precision they wish.
>
>
> OK, but that only pushes the problem space outward rather than  
> solving it.  Make CPUs 10x faster and then have one browser with a  
> floor of 1 ms and one with 0.1 ms and you have the exact scenario  
> we're in today.  Someone writes a tight loop in the 1 ms browser,  
> checks that it doesn't use too much CPU, and pushes the build, and  
> the 0.1 ms browser gets hosed.
>
> I admit that this one worries me a bit.

I was going to raise the same issue. Again, I'm wondering how many  
legitimate uses are there for short timeouts in background tabs/ 
windows. For example, the calendar app sets a timeout minutes, days or  
hours in the future and those timers could fire in the background.  
However, for timers set for under 1000 milliseconds, aren't these  
simply resorting to polling. By inhibiting timers when pages are in  
the background (especially with new timer APIs), we encourage web  
application authors to find more appropriate events to key off of.  
Polling may be a popular design pattern, but we should be thinking of  
ways to painlessly break that approach, not facilitate it.

Take care,
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/c0d3e998/attachment.html