Сущность слушателя события

[КорДум]

Всем привет. А что есть слушатель события на самом деле? Как часто он прослушивает нужное ему событие и когда именно? Почему не рекомендуется делать много слушателей у однотипных объектов и по возможности делать один слушатель у их контейнера? Чем грозят склеенные приемники событий у слушателя одного объекта?
Один вопрос - одна тема, но вопросы однотипные, объединенные одной и довольно конкретной темой.

[Wolsh]

1. То что ты пишешь вторым параметром в addEventListener. Функция, принимающая параметром объект данного события.
2. Не понял вопроса. Когда возникает событие, функция-обработчик вызывается и ей отдается событие.
3. Зависит от контекста, в котором это советовалось.
4. Что это - "склеенные приемники событий"?

[КорДум]

1. То что ты пишешь вторым параметром в addEventListener. Функция, принимающая параметром объект данного события.
Хм, это я в понятиях запутался, значит. Обратился к товарищу Муку, он называет этот метод приемником события.
2. Как часто флеш плеер проверяет, не наступило ли то или иное событие?
3. Скажем, пули добавляются в контейнер с пулями, пуль несколько десятков. Советовали делать один слушатель на весь контейнер и двигать эти пули в нем, а не вешать каждый слушатель на каждую пулю.

4. А вот здесь придется немного расписать:
Имеем класс А, в нем к stage присобачивается слушатель события enterFrame a()
Имеем класс B, в нем к тому же stage присоединяется слушатель того же события b()
Я правильно понимаю, что эти слушатели суммируются? Таких слушателей на stage, ловящих одно и то же событие, может быть больше, чем два. Чем это грозит?

[f.g.programmer]

2. Сразу, когда происходит dispatchEvent
3. ENTER_FRAME бросается из каждого отображаемого объекта, но если вы добавите обработчик в контейнер, у вас вызовется одна функция, если к каждой пуле, то вызовов будет столько, сколько пуль. Т.е. производительность хуже.
4. Грозит тем, что у вас не будет полной уверенности в том, какой обработчик вызовется раньше.

[КорДум]

2. Это и так понятно. Я хочу узнать конкретнее. Скажем, как часто ФП проверяет, нажали ли мы на кнопку? Раз в кадр? Или 100 раз в секунду?
3. А, ну я догадывался, что так оно и происходит.
4. Только это? Тогда нужно так проектировать код, чтобы не было зависимости двух методов-приемников.

[alatar]

2. По-сути все равно, можно принять: раз в кадр, ввиду того, что код выполняется раз в кадр, чаще вы его поймать не сможете.
4. Можно выставить приоритет, это даст некоторую гарантию последовательности.

[gloomyBrain]

Скажем, как часто ФП проверяет, нажали ли мы на кнопку? Раз в кадр? Или 100 раз в секунду?

Операционная систем опрашивает клавиатуру "Что у тебя нажато?" с какой-то частотой. С такой же састотой возникают события о нажатиях.


раз в кадр, ввиду того, что код выполняется раз в кадр, чаще вы его поймать не сможете.

Ерунда. Поставьте частоту кадров на 1 и посмотрите через trace

[КорДум]

alatar по-своему прав. Весь код выполняется раз в кадр. Думаю, все диспатчи событий в этом кадре тут же ловятся слушателями и обрабатываются в этом же кадре. Продолжаю думать дальше: ФП нет смысла проверять очень часто, был ли диспатч того или иного события. Ибо он может произойти только раз в секунду/FPS. Но как быть тогда с таймерами? Они разве настолько сильно привязаны к кадрам, что код метода их "тика" выполняется только синхронно с другим кодом? Хотя, там, наверно, выполнение метода по таймеру может варьироваться в очереди выполнения всего кода.
Логично же, нет?

Ерунда. Поставьте частоту кадров на 1 и посмотрите через trace
А вот здесь уже да. Получается, что опрос ФП того или иного события не зависит от FPS и ограничен только производительностью в текущий момент времени. Зачем это сделано? Все равно код при 1 фпс сработает только раз в секунду. Не вижу смысла ловить так часто.

[gloomyBrain]

Ибо он может произойти только раз в секунду/FPS

С чего Вы это взяли? Как только срабатывает ENTER_FRAME, начинают подряд выполняться все функции, которые переданы в параметр addEventListener. Выполняются они в том порядке, в котором добавлялись слушателю + в зависимости от приоритета.
Событий за кадр можно отправить сколько угодно. Пока все обработчики не отработают, мы на следующий кадр не попадем. Именно поэтому fps может падать при большой нагрузке - т.к. рендер привязан к коду (что, ИМХО, не всегда есть хорошо)

Вы поймите, что dispatchEvent практически ничем не отличается от прямого вызова всех слушателей (или, если хотите, прямого вызова функций). С той лишь разницей, что при dispatchEvent мы, в принципе, не всегда знаем, что будет вызвано

ЗЫ
То есть тут вообще никто ничего не проверяет, а просто выполняются нужные методы