I first sent this to Mike Belshe; I meant to send it to the list, but
I'm new to it:
Perhaps it could use milliseconds, but allow floating-point numbers.
Milliseconds would be easier, in my opinion, to work with than
microseconds.
Adobe's data type for delay is Number, which according to their
documentation, represents a double-precision floating point number.
However, they do not appear to use this precision -- although it is
difficult to test; I made a test which, after waiting one second for
the application to finish loading, ran a timer set for .1
milliseconds, set to repeat 100 times. The first event was a full
millisecond after the timer was called, and the entire repeat (each
interval was traced to the debugger) took consistently around 1700
milliseconds. For comparison purposes, I also ran it in a pure loop,
and the entire loop took 4 milliseconds.
As an aside, a similar test of setInterval on Webkit showed that 100
iterations completed in almost exactly 1000 milliseconds; almost
precisely 10 milliseconds per interval. It seemed more consistent than
Adobe's.
Alex
On Oct 1, 2008, at 11:16 AM, Mike Belshe wrote:
If you're going to propose a new API designed for hi-res timers, it
ought to use units of microseconds instead of milliseconds.
Mike
On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood
<[EMAIL PROTECTED]> wrote:
http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/
It's based off Adobe's "flash.utils.Timer" API that they have in
AS3. Once I get enough WK comments, I'll see about how to get it to
HTML5...
--Justin Haygood
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
