Ха,была у меня такая проблема,и я тут её решение несколько раз спрашивал,но увы.А сейчас хотел ответить, а проблему и решил.Так что забираю свои слова про clearInterval() обратно.Но getTimer()+onEnterFrame() реально точнее,и я просто написал себе класс scarbo_interval() и им пользуюсь.Но это дело вкуса.

У getTimer() погрешность, как выяснилось, тоже будь здоров.

Хм, у getTimer наличествует некоторая стартовая погрешность, плюс в любой момент времени при считывании в пределах точности системного таймера (20 мс). Накопляемой погрешности у getTimer я не встречал.

А мы встречали. Особенно заметно это в игре, после трех часов игры разница между двумя Date (стартовым и текущим) и значением getTimer() доходила до 25 секунд, что приводило к полной рассинхронизации.

и что же тогда предпочесть?

Свой getTimer, возвращающий разницу между стартом и текущим временем.

А в какую сторону была разница? getTimer() спешил или отставал от разницы, высчитанной между двумя Date?

Зависит от железа, версии плеера и операционки. Может отставать, может убегать.
Под Mac OS X разница равна нулю.

Вообще - это логично. Date вытаскивается из операционной среды, а getTimer() высчитывается самим ФП (как именно - понять трудно. Одно дело - он бы только отставал - это еще можно объяснить, а вот когда еще и убегать может... Выходит, что во ФП свои автономные часы, независимые от операционной среды).

Получаем погрешность 0,23% в общей сложности. если не сохранять предыдущий результат, а считать относительный - это пренебрежимо мало. Погрешность setInterval 3-20%. Ощутимая разница. а Date абсолютный различен, а относительный - точнее конечно, но ненамного.