Feature request для Flash Player 11

По-моему, это ошибочное мнение. Сделав один DisplayObject в AVM, его все равно придется дублировать плееру при рендере.
Экономии памяти, естественно, будет очень немного. Да и наши игро-мастеры не жалуясь выходят из самых, казалось бы, фатальных ограничений флешплеера.
Да и как же интерактивность? Это она сейчас вам не нужна. А завтра? Тогда вернемся к старому методу?

идея толковая, но только очень поверхностная. не учітаны моменты того, что экземпляр есть экземпляр, і его свойства станут едінымі для всех. решается например созданием некого контейнера для объектов ( как Bitmap для BitmapData ). что-то типа локализации stage для объектов. то есть делаем некий stage, который является контейнером. объекты внутри него не имеет выхода наружу ( тоесть цепочка parent.parent.parent должна привести нас к какому-то локальному stage ). событийная модель с баблингом тогда имеет право на жизнь, но становится не такой удобной. надо будет передавать массив контейнеров, что бы точно идентифицировать объект.

2BlooDHounD: она не толковая, просто может выглядеть привлекательной если смотреть на нее исключительно как скриптовый программер.
С битмапом – понятно, там в примере заранее ее сделали 20×20. Рендер = рендеру трансформированных битмапов. Это быстро.
Возьмем векторный DisplayObject, как говорите, в контейнерах. Рендер = рендеру транформированных векторов (вектор до трансофрмации не будет знать о подходящей степени дискретизации в растр и будет пробегать по всей внутренней структуре). Это медленнее, чем если бы я сначала сделал из него растр 20×20.
Есть же превосходный инструмент – работа с битмапом, который своей ограниченностью дает вам правильно разрабатывать.

pixelbender, Вы о чём? я не согласен с Вами в том, что трава зелёная.

2BlooDHounD:
- идея толковая
- нет, она бестолковая

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

Друзья, давайте попробуем разобраться в этом вопросе. Что даст возможность добавления экземпляра DisplayObject одновременно в несколько контейнеров? Простота обновления внешнего вида экземпляра DisplayObject одновременно во всех этих контейнерах. Однако в комментариях к оригинальной записи было подмечено, что при таком варианте, придется столкнуться со следующими трудностями реализации:

• может возникнуть рекурсия, когда один объект окажется вложенным в самого себя;
• неопределенность в поведении интерактивности и модели всплывающих событий;
• отсутствие свойства parent у DisplayObject;
• так как в таком случае экземпляр DisplayObject у нас один-единственный на разные контейнеры, то и свойства x, y и rotation этого объекта для всех его виртуальных копий будут общими. Следовательно в значение этих свойств для виртуальных копий экземпляра во всех контейнерах, в которых он присутствует, будут одинаковыми. Т.е., если в одном контейнере объект располагается в координатах x: 100 и y: 50, то и во всех других контейнерах объект располагается в тех же точности координатах, что не всегда оказывается удобным. Изменение какого-либо из свойств будет немедленно отражено на виртуальных копиях объекта во всех контейнерах;
• возможно, я что-то упустил.

В общем, как выяснил коллективный разум, возможность одновременного добавления экземпляров DisplayObject в различные контейнеры оказалась не самой блестящей идеей. В качестве альтернативы читатели предложили использовать один объект DisplayObject, как display source для других DisplayObject-ов.

2Юра: Давай попробуем.

1. Они рисуют N BitmapData и кидают N Bitmap-объектов. (Нахрен они так сделали? Картинка-то одна, зачем их N раз рисовать?)
2. Они рисуют 1 BitmapData и кидают N Bitmap-объектов. (Ну наконец-то догадались! Даже поняли, что память сэкономили. )

// Тут они долго думают и решают: блин какая подстава-то, пацанчики тут кидают N DisplayObject-ов, а вдруг он там N-раз рисуется, а?

PS: разработчики флеш-плеера истерично смеются глядя в джиру.

Не знаю относится это к топику или нет, НО в соответствии с недавними опросами выяснилось что gradient art нравится только 20% издателей\спонсоров. так что на векторных текстурах я б не стал экономить, я б их вобще не юзал… другое дело тайловый движок какой нибудь…

З.Ы откуда исследования не помню

Полезная вещь! Знаю из 3DS Max – есть там такая фича как Reference-клонирование. Эту особенность используют рендеры. Вот если в таком ключе сделать, то я обеими руками ЗА! Только бы рисовалось быстрее)