Насколько мне известно этой проблемы еще никто не решил. По крайней мере если кто то и решил то опубликовывать не спешит. Стандартные средства JS предназначенные для этого работают более менее только в одном браузере. Так что все "пингуют" пользователя всякими разными способами, либо замеряют паузу активности.

А есть ли средства flash что бы отследить свертывание окна браузера или переключения на другую вкладку?

Таких средств нет, никакие события не диспатчатся.

Были похожие грабли - вам надо привязываться не к кадрам, а к времени.
В 10.1 FP при смене/сворачивании вкладок ФПС понижается до 4х ( косвенно можно например так отследить), поэтому ваша анимация длится дольше.

А как же Event.ACTIVATE и Event.DEACTIVATE?

А если у человека FP ниже 10.1, а мы будем считать, что при потере фокуса плеер ушел в sleep mode?

И эти события отслеживают потерю фокуса, а это может быть просто перекрытие другим окном.

Note: No ActionScript event is dispatched when Flash Player enters or leaves sleep mode.

Присоединяюсь к вопросу. Вот игра, которая в паузу уходит, например http://www.kongregate.com/games/rich...r/hello-worlds

Предложили же отслеживать Event.ACTIVATE и Event.DEACTIVATE

Похожая проблема была у меня. Попробую описать.
Был один таймер, время его работы, примерно 1,5 сек, назовем его "Короткий таймер". И был другой таймер, его время работы 12 сек, пусть будет "Длинный таймер". Порядок их работы следующий:

1. Включается слушатель Короткого таймера.
2. Включается Длинный таймер.
3. Включается Короткий таймер.
4. Событие - Короткий таймер. По окончанию работы Короткого таймера включается слушатель Длинного.
5. Событие - Длинный таймер. Отключается слушатель Длинного таймера.
Дальше все это работает циклично по пунктам 2-5...

Так вот при сворачивании окна, или переключении на другую вкладку работа Короткого таймера резко замедлялась, судя по getTimer() на его работу уходило 18 сек. а не 1,5. А Длинный таймер работал примерно с такой же продолжительностью как и при открытом окне, если скорость и отличалась то незначительно. А вторая особенность была в том, что Слушатель Длинного таймера срабатывал, несмотря на то, что Короткий таймер не успевал его включить, ведь его работа стала продолжительней Длинного таймера. Слушатель Длинного таймера был отключен однозначно, проверял hasEventListener и willTriger, и тем не менее реагировал на событие окончания работы Длинного Таймера! Вот такая штука. Решилось это установкой в Слушателе инструкции if(hasEventListener)...
Баг это или не баг, незнаю, но покопав в этом направлении можно сделать модуль сигнализирующий о том, что пользователь свернул окно или перешел на другую вкладку. Ведь признака падения fps не достаточно, так как на сцене, к примеру, могут выполнятся ролики с разным fps.

Ну как вариант =)
А вообще можно еще через js и ExternalInterface попробовать - т.к. сворачивание браузера или переключение на другую вкладку есть события браузера, а не FP. Всякие там window.onBlur есть для этого

Это, интересно, как?

Хомяк

Одного знания FPS конечно недостаточно, так как может быть падение фпс.
Поэтому советую отталкиваться от временных промежутков, а не от кадров.

Таймер не может замедлятся сам по себе, фпс падает до 4, но промежутки времени определяются также.

http://www.flashgamesclassroom.com/c...sed-animation/

andrew9911 Вы правы, замедлялся он не сам по себе, это скорее процесс обработки графики построенный на таймерах, что бы упростить я назвал его Коротким таймером, возможно это было не очень правильно, но интересно не замедление само по себе. А то, что слушатель реагировал на событие будучи не активированным, более того, он сам знал, что он неактивен! Как вам это? "Привет! Я не активен. Н-н-на!!! Тебе событие!" :D. Нормально да?

А по поводу "onBlur"а - потому у нас все так криво и работает, что пытаемся прикрутить то что предназначено для другого к тому, что нам надо.:)