Comments 13
Хотелось бы увидеть не скрины, а численные показатели разницы FPS.
PS: Да, кстати, в «MyCach» неплохо бы поставить «e» на конце :)
PS: Да, кстати, в «MyCach» неплохо бы поставить «e» на конце :)
На скринах в левом верхнем углу разве не тот самый FPS?
P.S. Я бы посмотрел на еще 1 показатель, количество потребляемой приложением памяти. Кажется мне если кешировать все векторные анимации всех обьектов довольно крупной игры, то этот показатель не будет очень радовать.
P.S. Я бы посмотрел на еще 1 показатель, количество потребляемой приложением памяти. Кажется мне если кешировать все векторные анимации всех обьектов довольно крупной игры, то этот показатель не будет очень радовать.
Скрины приведены именно чтобы оценить FPS (увеличил чтобы было лучше видно, имя класса также поменял, проект перезалит).
На счет остальных показателей на приведенном тестовом примере:
-без кэширования: ЦП — 86-90%, память 17 мб,
-с кэшированием: ЦП — 30-40%, память 40 мб.
Тест проводился на конфигурации: Intel Celeron, 2033 MHz (20 x 102), 2 ГБ ОЗУ.
Показатель потребления памяти конечно возрастает, но без этого никуда. Причем на практике он гораздо меньше чем на данном примере, т.к. в большинстве случаев эффекты проигрываются не одновременно, а с каким то интервалом, за который некоторые уже успеваю быть закэшированными.
На счет остальных показателей на приведенном тестовом примере:
-без кэширования: ЦП — 86-90%, память 17 мб,
-с кэшированием: ЦП — 30-40%, память 40 мб.
Тест проводился на конфигурации: Intel Celeron, 2033 MHz (20 x 102), 2 ГБ ОЗУ.
Показатель потребления памяти конечно возрастает, но без этого никуда. Причем на практике он гораздо меньше чем на данном примере, т.к. в большинстве случаев эффекты проигрываются не одновременно, а с каким то интервалом, за который некоторые уже успеваю быть закэшированными.
И кроме того, как я уже указал, кэшировать необходимо не все объекты, а только те которые реально влияют на производительность.
Опцию cacheAsBitmap пытался установить с самого начала, особого прироста производительности это не дало, помогло кэширования каждого кадра в отдельный битмап. Кстати про приведенной Вами ссылке автор указывается именно на то решение, которое у меня находится в ссылках по теме (последнее по счету). Именно оттуда и бралась основная идея. Однако в статье я уже указал, что это решение адекватно только для клипов, у которых каждый кадр сам по себе статичен, с системам частиц такое уже не применимо. Также в примечании я указал, что для случая с фреймовой анимацией более адекватно кэшировать клип определенного типа один раз, а не каждый раз при создании экземпляпа.
я к стати вот только что сделал небольшой тест: создал анимированный крестик, расплодил на сцене их штук 100, нагрузка на проц была 13-16%. Потом дописал при инициализации им cacheAsBitmap, нагрузка поднялась до 16-20%…
имхо, использовать его надо умело только в отдельный случаях…
Как говорит Adobe «Свойство cacheAsBitmap лучше всего использовать для фрагментов роликов, в которых преобладает статичное содержимое и редко используется масштабирование и поворот. ».
Так что если ваша анимация как и моя содержит масштабирование и поворот то производительность может только упасть
имхо, использовать его надо умело только в отдельный случаях…
Как говорит Adobe «Свойство cacheAsBitmap лучше всего использовать для фрагментов роликов, в которых преобладает статичное содержимое и редко используется масштабирование и поворот. ».
Так что если ваша анимация как и моя содержит масштабирование и поворот то производительность может только упасть
спасибо за статью, но она как и предыдущая очень поверхностно раскрывает битмап рендеринг во флеше. Хотел бы почитать:
1.как определяете, что тормозит код или анимация?
2.рендеринг множества обьектов в одну битмапку.
3.«отвязка» фпс от скорости проигрывания анимации.
1.как определяете, что тормозит код или анимация?
2.рендеринг множества обьектов в одну битмапку.
3.«отвязка» фпс от скорости проигрывания анимации.
По поводу тормозов, адекватных средств их определения найти не смог (работаю во FlashDevelop + Fash CS5 для анимаций), поэтому определялись экспериментально. Для тормозов в коде производилось измерение скорости работы и кол-ва вызовов подозрительных функций (самодельный класс на основе getTimer). Для определения ресурсоемких анимаций производилась их замена на статичные клипы, с последующим сравнением кол-ва FPS (что собственно и подвело к идее о необходимости использования кэширования). По последним двум пунктам работа еще не проводилась, т.к. на данный момент результат вполне устраивает, однако в дальнейшем все таки планируется расширение функционала.
тогда по поводу тормозов подскажу:
профайлер и в результатах строки [pre-render] и [render]
Вся работа с вектором проводится именно в пререндере, соответственно глянув сколько он занимает можно наперед сказать сколько выиграете.
не думали взять готовую библиотеку битмап рендеринга до того как начали писать свое решение?
профайлер и в результатах строки [pre-render] и [render]
Вся работа с вектором проводится именно в пререндере, соответственно глянув сколько он занимает можно наперед сказать сколько выиграете.
не думали взять готовую библиотеку битмап рендеринга до того как начали писать свое решение?
Спасибо за подсказку). На счет библиотеки думал, но подходящих под задачу решений не встретил, в данном случае проще было часть отвечающую за кэширования реализовать вручную. В статье приведена только часть функционала, в оригинала из клипа производится не только рендер кадров, но и экспорт необходимой информации (в частности при кэшировании анимации персонажей для одной игры для каждого кадра считываюся ключевые позиции для привязки к ним эффектов крови и подобное).
Sign up to leave a comment.
Пример кэширования программных анимаций во Flash