我的猜測是每個時鐘的「滴答」過於密集,無法正確保持同步。爲了達到這個目的,你需要每個'tick'執行的操作儘可能接近即時。
在倒計時運行時查看DOM,顯示計數器使用每個「滴答」重新生成具有更新值的DOM片段。這本身並不會導致問題(我認爲),但將Cufon加入混合中會增加很多開銷 - Cufon需要重新索引新元素,讀取它們的值並重新呈現字體。
可能有一些原因,倒計時插件會在每次滴答時重新生成DOM,但乍一看,這似乎是一種低效率的方式。
如果你真的需要花哨的字體,我會使用@ font-face解決方案,或者像你說的那樣,使用一組圖像精靈。通過調整類操縱精靈地圖,可以讓你更新計數器而不用觸及DOM結構。不過,這需要構建您自己的插件版本。
UPDATE:
我想我可能對你有一些壞消息,夥計。我一直在修改一個很好的JavaScript計時器的基礎,我想我已經遇到了你使用的時鐘問題的根本原因。基本上,這歸結於Javascript的定時功能不是很準確,原因如下: 根據瀏覽器的不同,瀏覽器級定時器的分辨率只有10或15毫秒。 Javascript是單線程的,這意味着計時器事件進入隊列,拋出它們的計時。 我已經設置了一個基線測試,它能夠做到「正確」 - 保持所有需要按時快速運行的時間,並且由於「滴答」事件的排隊而自行糾正時間上的任何不準確情況。本質上,每隔20ms檢查一次,以找到最準確的點來更新顯示。我的機器上的每個更新需要1ms或更少(它低於Javascript的時間分辨率限制)。
現在,有90%的時間,這產生一個時鐘,它應該在20毫秒內更新它看起來不錯和精確。問題在於瀏覽器決定做其他事情時 - 使用另一個選項卡或瀏覽器內部的東西。然後,我們看到您注意到的嚴重滯後:在更新之前,顯示器可能會掛起一秒或更長時間。自我糾正,下一次更新跳回正確的時間,但它是明顯的,就像其他人一樣。用戶甚至不需要做任何事情 - 我可以坐下來看精確度讀數從5(ms),5,8,10,5,1300,5,5,800跳躍......不觸及任何東西。
因此,看起來我可能已經給你一個流浪漢 - 問題不在於你的更新代碼耗時過長(儘管效率低下可以改進),而是瀏覽器沒有設置爲準確定時準確定時。在這個階段,我沒有看到有辦法解決這個根本性的限制。
這裏的一些更多的閱讀,如果你有興趣:http://ejohn.org/blog/how-javascript-timers-work/,http://old.nabble.com/Proposal%3A-High-resolution-%28and-otherwise-improved%29-timer-API-td19791635.html
我有圖像這裏的精靈,但這裏面臨着同樣的問題是該版本http://dl.dropbox.com/u/2982102 /Moto/Countdown/%D0%A1ountdown%D0%A1lock_RC10/countdownclock/index.html – Quotient 2011-06-02 04:14:40
您是否決定使用您已經擁有的插件,或正在重新編寫自己的選項?我可以想辦法以一種非常有效的方式使它與精靈一起工作,但它不適用於你現在擁有的東西。 – Beejamin 2011-06-02 04:16:38
我已經直接向您發送了一封電子郵件。謝謝 – Quotient 2011-06-02 04:23:31