Оптимизация графической или скриптовой составляющей

[in4core]

Вопрос к гуру оптимизаций.
Допустим есть игра, графика вся растровая, подтягивается при загрузке с swf. Причем, для каждого ассета выставлено значение loseless/png - для макс качества и отруба зубцов.
Видео файлы же вставлены так, что для каждого видео фрагмента выставлен smoothing = true.

От чего могут возникать тормоза?
1) От сглаживания видео могут? Нагрузка сильнее?
2) Что с ассетами, стоит их передавать как jpg (100% безусловно ) или loseless/png одно и тоже по сути?
3) Может ли нагружаться память процессор в случае, если на поле добавлено скажем 50-100 клипов, размером 200*200, причем в каждом клипе 10 кадров забитых разными ассетами, а в 11 кадре - видео фрагмент? Стоит ли убрать видео фрагмент ( хотя перехода на него нет, пока не наступит определенное условие) и подгуражать( подставлять) его только в нужный момент? или это ничего не решает?

Какие еще могут быть проблемы? ( скриптовой части типа циклов в 1000000 элементов и т.п. - нет, все предельно просто ) Едиснтсвенно то, что большенство ассетов и клипов находятся всегда на сцене - просто с visible = false, но при этом они stop() на первом кадре, где обычная картинка

[Akopalipsis]

Мне кажется тут и гуру быть не нужно, чтобы понять, что сглаживание очень затратное решение.

Добавлено через 1 минуту
Мне вообще кажется, что это самое затратнее уже не чего нет.

[in4core]

Akopalipsis - вы только начали разбираться в AS3 - и во флеше в частности. Без обид - ваш совет не о чем.
Тем более везде сказано, что переход на видео файл ( на кадр ) со сглаживание осуществляется в определенных условиях, а не постоянно висит на экране, при этом - тормоза имеются

Добавлено через 2 часа 3 минуты
Так же дополню. stage.quality = BEST ( имеет значение , если на HIGH перевести например?). Во вторых плеер 11.1 - в новых версиях оптимизация получше будет ( 11.3-4 например) ?

[СлаваRa]

если графика лежит в кадрах, то во-первых, при каждом заходе в кадр происходит создание того что там лежит, во-вторых даже если вы туда положили битмап, то после компиляции он станет вектором.

[in4core]

если графика лежит в кадрах, то во-первых, при каждом заходе в кадр происходит создание того что там лежит

Не понял фразы ни разу. Вот есть мувиклип с 10 кадрами. в каждом из кадров по битмапе. Мувиклип всегда в списке отображение, не удаляется. Перешел я с первого на 2й кадр и что? Просто обновилась( пересоздалась) картинка. Это минимальная нагрузка. Таких элементов не 1000 и не 10000. а всего то 50, с мини битмапами. Во вторых в вектор ничего не переводится, это уж точно, иначе бы данную картинку можно бы было тянуть ( изменять размер ) в меньшую или большую сторону, без потери качества. Потеря качества ТОЛЬКО на битмапе.

Добавлено через 4 минуты

если графика лежит в кадрах, то во-первых, при каждом заходе в кадр происходит создание того что там лежит

Опять же по этой фразе добавлю. 50 клипов. В течении 2х секунд нужно в каждом рандомно менять картинку из 10 возможных. Потом пауза, потом опять. Некий шаффл, например. Если по тайм эвенту или по интерфйему я буду вызывать addChild/removeChild - и ставить новую картинку, это будет нагрузочнее чем переходить по кадрам в клипе - уж точно. К тому же вариант с аддчайлдом невозможен, дабы в каждом клипе кроме 10 кадров есть еще анимированная составляющая, вручную и т.п. - перевести это чисто в код - дико неловкая операция, да и не делает так никто

Добавлено через 6 минут
Что самое интересное сменив плеер с 11.1 до 11.3 - увеличили скорость работы приложения на 80%. Значит все таки оптимизируют они флеш плеер с релизами версий.

[C4Grey]

Может это и банально, но советую попробовать Adobe Scout, очень удобная для таких случаев штуковина: насобирать данных, скажем, за минуту работы флешки, и потом смотреть, на что больше всего тратится времени CPU. Что касается версии плеера, актуальный вроде 11.8 уже? Или есть какие-то причины не использовать поздние версии?

[KumoKairo]

in4core, не забудь сделать релиз билд для проверки производительности

[КорДум]

Во вторых в вектор ничего не переводится

Переводится. Слава только не пояснил, что не сама битмапдата, а битмап. Он становится векторным шейпом с заливкой из своей битмапдаты.

Перешел я с первого на 2й кадр и что?

И предыдущая битмапдата диспозится, новая создается. И так каждый раз. В каждом кадре каждого клипа. Никакого пулла, все время новые экземпляры. Это сжирает ресурсы, выпрашивая, к тому же, GC поработать еще раз и еще раз. Тем более, если еще и сглаживание, которое дает дополнительную нагрузку на процессор. Тем более лосслесс. Из мелочей утечек и нагрузок и складывается проблема на ранних версия плеера, где что-то не было оптимизировано.

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

[in4core]

КорДум - тут разговор не о нашем старом проекте, это совсем другое. Тут не HD ваидео и т.п. тут видяхи 200*200 размером всего лишь, без альфа и т.п. - не нагружают они. А вот про то что в каждом новом плеере идет оптимизация - слышу первый раз, вроде как в релизах не писали о какой то оптимизации по нарастанию версий 11 плеера, при переходе с 10 на 11 - да, но тут непонятно. В любом случае, как это не странно, как я уже написал, даже на самых слабых компах тормоза пропали из за смены плеера до 11.3.

[КорДум]

in4core, а где я сказал про наш старый проект?
Видео жрет ресурсы в любом виде. Чем больше видео, тем больше оно жрет ресурсов. Чем больше объектов видео, тем больше они жрут ресурсы. Про FullHD это был оффтоп.
Нет, ну логично, что выпуск нового плеера — это не просто введение нового функционала и новых возможностей, но еще и устранение ликов и багов, найденных другими и опубликованными в адобовскую жиру, верно? Не понимаю, чему тут удивляться.