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] http://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]
