And, Thanks...relying on new Date().getTime() sounds much more solid than hoping the timers remain consistent.
-Vince On Jan 15, 6:37 am, And Clover <[email protected]> wrote: > On Fri, 2011-01-14 at 16:24 -0800, foldi wrote: > > I have an upcoming project that involves multiple timers and need a > > response if someone asks, "Where's the missing time?". > > Any long-running script or plugin, even on another page in the same > browser, can cause timers to stop firing for extended periods of time, > causing the fire time to be much later than the scheduled time. Leaving > and re-entering the page (with bfcache), or putting the computer to > sleep, can also cause timers to fire much, much later than expected. > > So anything that requires attention to actual real-world elapsed time > needs to be looking at the current clock timestamp (eg `new > Date().getTime()`) rather than relying on intervals/timeouts. For > consistent results with interacting concurrent timers, you may in the > worst case need to write your own scheduler, that fires on a short > intervals and dispatches callbacks based on real time. > > Unfortunately there is still the problem of what happens if the user > changes the clock time in between timer scheduling and firing. (Or if > the OS automatically does it without user intervention.) What happens in > this case varies amongst the browsers, but is not anything good. There > is currently no interface for scripts to read a ‘monotonic time’ > independent of the clock time. > > -- > And Clover > mailto:[email protected]://www.doxdesk.com > skype:uknrbobince gtalk:[email protected] -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
