jquery countdown clock lag/jump

I have a countdown clock that I have been working on. If you watch it for several seconds you will start to notice that it will occasionally hang or jump a bit when counting. Its subtle but... obvious. We have tested on lot of browsers and os's and the problem seems to be consistent and we just arent sure what to do on this. Oringially we had image sprites for the font but changed that thinking that we had some http request leaking by but now that we have changed to cufon we still see the same exact problems.

Another update we made is to set th开发者_StackOverflow中文版e interval time to 500ms but we still seem to be stuck

http://dl.dropbox.com/u/2982102/Moto/Countdown/Cufon/markup-new/countdownclock/index.html

Any help would be awesome on this.

---

My guess is each 'tick' of the clock is too intensive to stay in sync correctly. For this to work, you need the action performed by each 'tick' to be as close to instant as possible.

Looking at the DOM as the countdown runs shows that the counter rebuilds the DOM fragment with the updated value with every 'tick'. This on its own wouldn't cause a problem (I think), but adding Cufon into the mix adds a LOT of overhead - Cufon needs to re-index the new elements, read their values, and re-render the fonts.

There could be reasons that the countdown plugin rebuilds the DOM every time it ticks, but on first glance, it seems like an inefficient way to do it.

If you really need fancy fonts, I would either use a @font-face solution, or like you said, use a set of image sprites. Manipulating a sprite-map by adjusting classes would allow you to update the counter without touching the DOM structure at all. This would require building your own version of the plugin, though.

UPDATE:

I think I might have some bad news for you, mate. I've been tinkering with the foundation of a nice javascript timer, and I think I've run into the root cause of your problems with the clocks you've been using. Basically, it comes down to the fact that Javascript's timing functions are not very accurate, for a couple of reasons: The resolution of the browser-level timer is only down to 10 or 15ms, depending on the browser. Javascript is single-threaded, meaning that timer events go into a queue, throwing their timing off. I've set up a baseline test which does everything 'right' - keeps everything that needs to run on time small and fast, and self-corrects for any inaccuracies in the timing, due to the queueing of the 'tick' events. Essentially, the tick checks every 20ms to find the most accurate point to update the display. Each update takes 1ms or less on my machine (it's below the limit of Javascript's timing resolution).

Now, 90% of the time, this produces a clock that updates within 20ms of the exact time it should, which looks nice and precise. The problem is when the browser decides to do something else - with another tab, or something internal to the browser. Then, we see exactly the lag you've been noticing: the display can hang for a second or more before it updates. Being self-correcting, the next update jumps back to the right time, but it is definitely noticeable, just like with the others. The user doesn't even have to be doing anything - I can sit and watch the accuracy readout jump from 5(ms), 5, 8, 10, 5, 1300, 5, 5, 800... without touching anything at all.

So, it looks like I might have given you a bum steer - the problem isn't that your update code takes too long (though there are inefficiencies we could improve on), it's that browsers aren't set up to give accurate timings at accurate intervals. At this stage, I don't see that there's a way to work around this fundamental limitation.

Here's some more reading, if you're interested: http://ejohn.org/blog/how-javascript-timers-work/, http://old.nabble.com/Proposal%3A-High-resolution-%28and-otherwise-improved%29-timer-API-td19791635.html