Скорость работы addChild() и removeChild()
 

Собственно передо мной стоит задача при выполнении которой будет необходимо довольно часто добавлять/удалять объекты (делаю скроллилку большого количества объектов и для того, чтобы сократить нагрузку как на память так и на ЦП хочу рисовать только те ячейки содержимого, которые будут попадать в область видимости).

Очень много наслышан о том, что методы addChild() и removeChild() занимают много процессорного времени. Я так понимаю, что это связано с тем каким образом в AS3 работают события, а потому помимо добавления объекта в список отображения происходят некие построения связей между объектами.

Так вот очень хотелось бы узнать насколько на самом деле плохо часто добавлять и удалять объекты.

В качестве альтернативного решения пробовал использовать bitmap'ы срисованные с оригинальных объектов, но надо сказать это довольно неудобно и порождает проволакивание за собой всяких «хвостиков» обязывающих на каждое изменение «родного» мувика не забывать перерисовать битмапу. Ну и да, это несет в себе определенный ряд проблем, если есть необходимость сделать содержимое интерактивным (например, сделать возможность поставить галочку в ячейке).

Может быть есть возможность хранить мувики в каком-нибудь «буффере» чтобы исключить операции не касающиеся непосредственно отображения?

Малоизвестный факт про добавление/удаление в списке отображения:
http://flashgameblogs.ru/blog/actionscript/32.html
Т.е. объекты быстро удаляются из начала списка отображения (removeChildAt(0)).
По логике, добавляться тоже должны быстрее в начало(сам не проверял, там всётки есть проверка на наличие объекта и просто ли они по parent смотрят или по списку бегают - не знаю)

А вообще по поводу производительности addChild/RemoveChild - оно всё в AS3 не быстро работает, даже a > 0 ? a : -a работает в несколько раз быстрее Math.abs(a), потому что вызов функции жутко медленный. Так что если проблем нет - не заморачивайтесь с отрисовкой в битмап-дату (там надо очень хорошо знать что делаешь, иначе только медленнее получится)

Что касается событий:
- ADDED_TO_STAGE, REMOVED_FROM_STAGE, и т.д. вобщем не создаются, если на них не подписываться, ну проверка наличия слушателя выполняется, но это не дорого.
- Мышиные события могут вызывать тормоза при большом количестве объектов (сама проверка положения мыши не дешёвой становится при таком количестве). Лечится сначала выставлением всяческих mouseEnabled/mouseChildrenEnabled в false, а потом удалением выходящих за пределы экрана спрайтов из списка отображения(в памяти они никому не мешают даже в больших количествах, достаточно из списка убрать). Проверяется, в обработке ли событий дело, тем, что fps падает при двидении мышью над флешкой.

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

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

Хотел бы поинтересоваться, уж покуда зашла речь, почему вызовы функций происходят медленно, есть ли способы оптимизации?

Ну и насчет битмап даты. Я просто брал прямоугольник в который срисовывал все содержимое мувика и перекладывал его на битмапу которую отображал. В чем потенциально могут крыться проблемы?

Это нативная вещь, её разработчики флешплеера и компилятора должны оптимизировать.

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