Как MovieClip's хранятся в памяти?
 

Здравствуйте. Есть классы игровых персонажей MyMC1, MyMC2, MyMC3...( extends MovieClip), в них по 40-60 кадров покадровой анимации. Таких персонажей 20-30(20-30 разных мувиклипов). Они все бегают по игровому полю, проигрывается их анимация бега, битвы и т.д. - тут все понятно. Но, есть в игре такая фишка, как библиотека - где пользователь может просмотреть характеристики каждого перса. Так вот при создании такой библиотеки у меня возник вопрос, как впихнуть туда персонажей:
1. Создать 30 новых обьектов MyMC1, MyMC2...MyMC30 и остановить их на первом кадре.
2. Создать 30 новых обьектов MyMC1, MyMC2...MyMC30 и отрисовать их в 30 битмапов.
Первый вариант мне сразу не понравился, так как в каждом из 30-ти мувиков 40-60 кадров разной графики (в моем случае растровой), оно же, наверное, будет жрать памяти много. Прежде чем приступить к способу 2 и изобретению велосипедов, решил поэкспериментировать с getSize(). Когда я увидел, что пустой new MovieClip(), MyMC1 и MyMC2 с разным количеством ключевых кадров - все весят 432 байта, я подумал что я тупею.
Поэтому обращаюсь к вам товарищи: какой способ лучше и почему. Почему в разных экземплярах одинаковый размер(где же информация о ключевых кадрах, графическом содержимым)? Заранее благодарен.

Спасибо, dimarik, но там немного не о том. В моем случае не будут анимироваться картинки с помощью copyPixel и пр, речь идет именно о MovieClip.
Наверное, я неточно выразился: есть 30 разных мувиклипов (30 разных классов). В игровой "библиотеке" есть список этих мувиклипов. Каждый мувиклип нужно разместить в этой "библиотеке" и остановить его на первом кадре. Чтобы пользователь увидел 30 разных не движущихся персонажей. Поэтому вопрос: как с технической точки зрения их разместить? Создать 30 разных не движущихся мувиков, или 30 разных батмап?

Добавлено через 6 минут
Почему такой вопрос возник, потому что интересно, что будет жрать меньше памяти. Ведь логика подсказывает что маленькая битмапа 50Х50 будет весить меньше чем мувиклип с сотней таких маленьких битмап. А мне же нужен только картинка первого кадра...

Добавлено через 9 минут
А getSize() показал, что не важно - один кадр в мувике, или 1000 - он все равно весит 432 байта. Если так, то зачем мне мучится и отрисовывать мувики в битмап, если можно просто оставить их как есть, да вот только, не сильно верю я этому getSize().

В MovieClip хранится только информация о картинках, а сами картинки берутся из библиотеки, т.е. грубо говоря, в классе мувика они не хранятся - хранится только информация об их местонахождении. В памяти они будут создаваться по мере необходимости, т.е. если какая либо картинка в мувике создается на втором кадре к примеру, то при создании мувика ее и не будет, пока не проиграется второй кадр. А вообще памяти меньше будет жрать второй вариант, т.к. в мувике кроме самой картинки хранится еще доп информация о твинах, матрицах преобразования и.т.д. Да и отрисовка битмапа будет происходить быстрее, чем мувика с аналогичной картинкой.

Добавлено через 3 минуты
А для измерения размера реального размера занимаемой памяти, можно замерить объем занимаемый флешкой до и после создания мувиков и битмапов, и соответсвенно, после, и сравнить результаты.

Наконец - то. Спасибо Stitch512. Выходит, не важно сколько я создам экземпляров со сложной анимацией, оно памяти будет жрать не больше чем простые мувиклипы... А информация об ОДНОМ графическим содержимым ВСЕХ экземпляров будет хранится в одном месте...

Второй вариант расходует больше памяти, но он быстрее.

Инструкция DefineSprite создает мувиклип. Каждый его кадр всегда создается заново. Делают это наборы инструкций PlaceObject, PlaceObject2, RemoveObject, RemoveObject2, и некоторые другие. В качестве добавляемого объекта может служить шейп, залитый битмапой. Этот шейп, а также битмапа уже единожды созданы (аха, в "библиотеке") и имеют свой уникальный идентификатор. Т.о. PlaceObject2, например, может "положить" шейп No. 1 в первый кадр. Шейп, в свою очередь, имеет список команд для создания очертания кривыми Безъе, а также инструкцию по заливке фигуры битмапой No. 2. Можно охарактеризовать это "программой" действий. Учтите, что такое "рисование" отнимает кучу времени.

Программы у двух экземпляров мувиклипов, как вы догадались, одинаковые. Алгоритм кеширования, запускающийся по установке акцессора cacheAsBitmap немного спасает однокадровый мувиклип тем, что раз отрисованная программой битмапа хранится в памяти, и по наступлению нового кадра нет необходимости проигрывать сборку заново, — для рендера будет использована именно она.

Во втором варианте есть уже отрисованные битмапы. Они жрут память и ждут когда их закинут на рендер.

Добавлю, что класс flash.display.MovieClip и мувиклип как DefineSprite, — это как ценник и товар. Ценник всегда имеет один и тот же размер )

Я, просто, думал, что если разместить на сцене 30 мувиклипов по 100 кадров каждый(в каждом кадре одна картинка) - в итоге в память будет забито 30х100 кадров информации (3000 разных картинок). Так как мне не нужна, анимация, а лишь статическое изображение первого кадра каждого из мувиков, то думал создать 30 клипов, отрисовать их в битмап и обнулить клипы. В итоге я бы получил 30 картинок, вместо 3000. Но, оказывается, что это глупость - и существенной разницы между двумя вариантами нет. Процессорные вычисления меня не особо волнуют, так как операцию надо проделать лишь один раз в приложении - и больше эти мувиклипы не изменяются и не анимируются. Спасибо всем за внимание.

Добавлено через 8 минут
Еще раз пересмотрел свои посты, наверное ничего непонятно из-за слова "библиотека". Это не та библиотека флешовская, а простой спрайт, в котором нарисованы 30 персонажей. То есть - картинка (статическая, недвижущаяся, неанимированная, мертвая), на которую пользователь будет смотреть и видеть что в игре бывают: драконы, бомжи, кролики, джастин бибер, рыцари, мотоциклисты и т.д.