погоди. а у тебя stop() перед эти кодом не стоит? потому что может быть оно зациклилось? и обьявление функции идет каждый раз и поэтому когда увилеичил фпс то кол-во декларирований увеличилос или я чего то путаю

код

var prevtime : Number = getTimer();
_root.onEnterFrame = function()
{
trace(getTimer() - prevtime);
prevtime = getTimer();
};

тоже не всегда выдает стабильный результат. Правда, тут погрешность не такая, но наводит на размышления (например, фпс = 15, трейс =
47, 68, 70, 66, 66, 66, 72, 67, 71, 66)

код пришлось чуть чуть подправить для AS2
cx=0
u = function () {
_root.cx++;
if (_root.cx == 20) {
clearInterval (id);
for (i = 1; i < arrayID.length; i++) {
trace (arrayID[i] - arrayID[i - 1]);
}
}
arrayID[arrayID.length] = getTimer ();

};
arrayID = new Array ();
id = setInterval (u, 100);

результаты и правда чет рознятся
На 20 фпсах
105,100,101,106,104,104,101,104,101,104,101,104,101,104,100,101,104,101

на 5 фпс
101,120,120,119,101,120,120,119,101,120,120,119,100,100,101,120,119,101

На 11 фпс
180,180,180,180,180,180,180,180,180,181,188,180,180,180,180,180,180,180

Заметил что самые точные интервалы при фпс кратные 60. Помойму этот баг обсуждался в флешрипере, связанно с округлением.

Статья называлась Волшебная частота.

Но там говорилась, что ошибка накапливается, а не каждый раз возникает. Все таки разница почти в 2 раза (180, а не 100) это много.

И кроме того, это показывает, что есть зависимость setInterval от fps.

Кому надо супер точность, может ввсести поправочный коэффициент, который определяем методом тыка......

и главное зависимость не пропорцианальна от кол-ва фпс. кривенькая функция получилась=(

кстате при интервалах около секунды погрешность не такая уж и большая примерно около 5-20 процентов.

А погрешность на фпс (к примеру 10, 5, ) и интервалом в секунду вообще отсутствует!!!

Атомные часы не получится сделаеть=)

Ка отсутствует? У меня при fps 5, 10, 12 и интервалов 1000мс, выдавалось 1040-1060.

Зависимость есть не прямая.

Колин Мук. ActionScript for Flash MX: The Definitive Guide, 2nd Edition

When an interval is set to run less often than the duration of a tick of the frame rate, it will execute on the frame after the interval time has expired. For example, given an interval set to 400 ms and a frame rate of 10 fps (1 frame per 100 ms), Table 18-16 shows the frames on which the interval should execute.

Frame number | Total time (milliseconds) | Interval executed?
000 | 0 | no
001 | 100 | no
002 | 200 | no
003 | 300 | no
004 | 400 | yes
005 | 500 | no
006 | 600 | no
007 | 700 | no
008 | 800 | yes
009 | 900 | no
010 | 1000 | no

However, whether an interval runs more or less often than the frame rate of a movie, interval times are by no means guaranteed. In an actual test movie, the intervals in Table 18-16 may execute at frames 5 and 9, or even at frames 4 and 9. Code execution, Player rendering, and available system resources can all affect the actual timing of intervals. Where time is an important factor in an application (for example, in a game), functions should be written to account for variance in interval times.

Русского издания под рукой не было

Перевод (у меня был под рукой):

Если интервал задан так, что промежуток между его выполнениями больше, чем промежуток между тактами частоты смены кадров, то он будет выполняться в том кадре, который появится по истечении времени интервала. Так, если задан интервал длительностью 400 мс и частота смены кадров состовляет 10 с-1 (1 кадр каждые 100 мс), то таблице можно узнать, в каких кадрах будет выполняться интервал.
кадр|мс| выполнен интервал?
000 | 0 | no
001 | 100 | no
002 | 200 | no
003 | 300 | no
004 | 400 | yes
005 | 500 | no
006 | 600 | no
007 | 700 | no
008 | 800 | yes
009 | 900 | no
010 | 1000 | no
Но ка бы не выполнялся интервал по сравнению со сменой кадров фильма - чаще или реже, временные промежутки интервала не могут быть гарантированы...

Но это не отвечает на вопрос почему при fps 12-13 такие большие искажения.

а не мог бы скинуть эту книгу на gaploid@yandex.ru
она большая?