Comments 49
Больше интересует почему даже на растровой графике флэш подтормаживает (в сравнении с C++ приложениями)? Т.е. сотня спрайтов вполне могут «убить» фреймрейт, при этом нативное приложение с такими же объектами даже не поперхнется.
Это я понимаю, мне интересно что обуславливает эту специфику.
Я понимаю почему код может тормозить, но вот отрисовка графики… Может она совсем софтварно рисуется, даже без 2D ускорения?

Очень надеюсь, что в октябре Адоб анонсирует нечто приятное и быстрое :)
«нативное» 3d и в 10 есть, есть даже некая аппаратная акселерация, другой момент в том, что даже тот же дроТрианглс реализован весьма криво…
Нативное 3D в десятке? Мм… Что-то мне подсказывает, что его обещали, но так и не сделали. И всякие Alternativa3D и PaperVision работают полностью софтварно.
Нет акселерации для 3D графики в 10-ке. Т.е. треугольники рисуются софтварно.
проблема втом, что флеш из начальных времен призначен был для анимации, тоесть каждый кадр прорисовывается, а это очень нагружает даже для растровой графики. Потому неизвесно когда будет быстрее все зависит от программиста… Прорисовку все же можна контролировать но не всю…
Еще пользователь может увидеть разницу увеличив масштаб при воспроизведении клипа. Растровый кэш, как и положено растровому изображению, при увеличении разваливается на пиксели, а вектор останется гладким. На мой взгляд это незначительный минус и наверное с этим можно бороться, но в приведенном примере происходит именно так.
Это уже не критично, для пользователя, он этого никогда не увидит.
Честно говоря мне кажется что статья по сути для блога «я пиарюсь», так как представленая информация из разряда «трава зеленая» — всем кто в теме и так ясна.
да согласен что большая часть статьи полный пиар :) но всё таки способ кэширование анимированной графики я к сожалению до сих пор не знал :(
Копипащу свою шпаргалку по флеш-оптимизации. Если интересно, как-нибудь подробно статью можно написать.

1. Меньше new.
2. Одна BitmapData на кучу Bitmap если они одинаковы.
3. cacheAsBitmap если не применяем трансформаций к объекту. Очень ускоряет фильтры.
4. opaqueBackground если не нужна прозрачность.
5. Избегать обращений к элементам массива в цикле через квадратные скобочки там, где это возможно.
6. Объект не рендериться если visible=false или он вне пределов видимой сцены. Но процессорное время на обсчет этого объекта тратиться, так что используем removeChild.
7. visible=false лучше чем alpha=0;
8. Прозрачность тормозит. Фильтры тормозят. Массивы тормозят. new тормозят.
9. Оптимизируем векторные изображения.
10. Точечная нотация в циклах тормозит. Перед циклом создаем переменную которой присваиваем длинную строку с кучей точек.
11. Все к чему часто обращаемся лучше сделать многоразовым, использовать заново вместо создания и удаления.
а про квадратные скобки для массива, пожалуйста, можно подробнее?
может имеется в виду использовать for each… in где это возможно?
Я бы не стал советовать всегда юзать removeChild() вместо visible=false.

Есть куча место, когда именно visible будет работать быстрее. Особенно если вам приходится постоянно добавлять/удалять один и тот же мувик.
3 — разве автоматом не врубается?
5 — тоже попрошу разяснений :)
6 — если очень много скрытых интерактивных элементов (тыщи), то прозиводительность можно поднять в разы этим методом.
8 — особенно тормозят твины по прозрачности. А с массивами-то что делать? Мне нужен быстрый и надежный хаштейбл, есть такой?

От себя добавлю
а) не вешать никаких особых перерисовок на маус_мув, лучше на ентер_фрейм
б) не везде нужен фреймрейт 30, для многих приложений достаточно 15 и даже 10 — пожалейте юзера и разгрузите ему проц. Видео будет кстати работать нормально.
masnart
3. Автоматом casheAsBitmap = false. Собственно об этой фишке статья.
5. Доступ arrayVar[i] является тормозным, поэтому если в цикле вы несколько раз используете arrayVar[i], то вроде как лучше сделать var tempVar:type = arrayVar[i] и использовать эту переменную.
8. Вообще массивы это отдельный разговор. Очень интересно почему они такие тормозные и как это исправить. Хотя где-то находил что в следующих версиях языка сделают типизированные массивы.

К стати о фреймрейте пришел к тому что делаю асинхронную работу перерисовки и цикла с логикой. То есть привязка не на ентер_фрейм, а на таймер. Есть свои плюсы и минусы.

soulburner
Ни в коем случае ничего не советую, всего лишь копипаста из моей шпаргалки. Опыт у меня не такой, чтобы советовать. По каждому вопросу, по хорошему, надо гуглить подробнее. Пункт 6 частный случай текущего проекта, поэтому в шпаргалке. К стати в этом проекте visible = false, дает мне больший выигрыш.

trueowl
Ок. Спасибо за интерес, постараюсь сделать.
If you apply a filter to a display object, the cacheAsBitmap property of the display object is set to true. If you remove all filters, the original value of cacheAsBitmap is restored.
www.adobe.com/livedocs/flash/9.0/ActionscriptLangRefV3/flash/filters/BlurFilter.html

У меня еще прирост из-за того что я на стейж_ремув отписываюсь от всех лишних событий, а потом снова записываюсь на адед_ту_стейж. Такое имеет смысл делать когда есть много скрытых объектов (например за экраном), которые еще и имеют наглость чегото-то слушать. Oсобенно если это ентер_фрейм!
Спасибо. А я то думаю, какого фига все летало, а как только rotation добавил, тупить стало!
Хотя где-то находил что в следующих версиях языка сделают типизированные массивы.


Ну как бы они уже есть. Называются Vector.
Пишется так: Vector.Вроде как на 30% быстрее.
Почему же сразу «украли»?

Мы скрестили Spore и MyBrute. Где-то такое на флэше было?
за правду не ругают :) мне кажется сама цель статьи был хитрый ПИАР :))) ну это моё мнения
С помощью не ругающих у меня карма растет разве если ее оценивать по абсолютному значению ;)
Чистейший? Объяснена суть кэширования. Приведен пример на сторонние исходники для кэширования анимаций (все знали об этом классе?), объяснен принцип их работы.

Плюс ссылка на наше приложение и скрин, да.

Пиар есть, но полезной информации тут гораздо больше.

ИМХО.
не не не кто не спорит что вы открыли принцип оптимизации Flash через кэширование :) это вы молодцы, как я и описал выше кое чего я вобщем то и не знал :)) спасибо ещё раз вам!
Заявленное содержимое: «Производительность и оптимизация отрисовки графики во Flash».
Фактическое содержимое: «врубайте cacheAsBitmap» и «вот ссылка на нашу игру».
Посмотрел на вашу игру...) С производительностью вы перестарались)) Бой прошел за 2 секунды, я ничего не успел рассмотреть))
не бой какой то не айс честно слово :))) ну не люблю я такой принцип боя во флэш ))
>>>Приложению будет доступно Ваше имя, дата рождения, фотография, список друзей и базовая информация на странице.

Зачем? o_O
У меня дилетанский вопрос. Как сделать плавное (без подергиваний) медленное передвижение картинки (не вектор) во флеше?
Я обычно рисую все в битмап, а потом уже вывожу на экран, в главный битмап рисую так:

matrix.tx = sx;
matrix.ty = sy;
BITMAP.draw(imageBitmapData, matrix, null, BlendMode.NORMAL, null, true );
Подергивания, как я понял, у вас либо из-за того, что вы координаты int указываете (а нужно Number), либо из-за того, что copyPixels используете, а нужно как я выше написал.
>Решение для анимированных клипов.
На практике данное решение действительно выгодно только в довольно узком диапазоне при соблюдении условий:
1. Много экземпляров одной и той же анимации, а не разных.
2. Анимация выполнена в одном таймлайне, без вложенных анимаций.
3. Анимация имеет малое число кадров (для большого числа кадров придется делать перевод в раст итерациями в разных стеках вызова, иначе флеш плеер будет подвисать на слабых системах)

И еще минусы:
1. За прирост производительности придется заплатить памятью, чем длиннее анимация и большее ее линейный размер, тем больше расходуется памяти. По сути метод делает пререндеринг всей анимации и хранит в памяти растровое изображения каждого кадра, в то время как флеш плеер рендерит только текущий кадр, удаляя из памяти остальные кадры.
2. При масштабировании всей сцены придется либо обновлять растровую карту анимаций, либо смотреть на пикселы (увеличение) или не сглаженные границы (уменьшение)
Only those users with full accounts are able to leave comments. Log in, please.