[Dukobpa3]

В анимациях это вообще не оправдано.

Добавлено через 10 минут
Про анимацию построенную на времени тоже писали.
Анимацию надо строить на энтерфрейме. Но можно мерять время с предыдущего кадра, чтобы иметь возможность подогнать ее.

Например спрайт должен пролететь 100 пкс, за 2 секунды.
Допустим у нас 60 кадров в секунду.
16.67мс на отрисовку одного кадра.
20мс на один пиксель.

Вот мы и считаем. Стандартная наша скорость будет ~3пкс за 4 кадра.
Если с предыдущего кадра прошло больше чем 20мс(вместо 16.67) - значит смело подвигаем на целый пиксель или больше, в зависимости от задержки. Если меньше (что маловероятно) оставляем на том же месте, но сохраняем в буфер "не использованную задержку" чтоб на следующем кадре посчитать всё вместе.

Я скидывал свой менеджер анимаций в какой-то из тем. Там это реализовано есть. Но там покадровая анимация, чтоб можно было с нужно скоростью анимации проигрывать. С твинами будет так же.

Добавлено через 12 минут
а updateAfterEvent - теоретически вызывает отрисовку немедленно, что очевидно, еще более нагружает систему. А нам при отставаниях ее наоборот разгрузить надо. (Могу ошибаться, так как пользовался этой функцией всего один раз).
Да и вцелом не вижу смысла в updateAfterEvent. Оно и так и так в следующем кадре отрисуется, такова уж система работы флеша. И если он понадобился скорее всего проблема в другом месте. Но иногда, например при драг-ен-дропах - это необходимо.