Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Больше интересует почему даже на растровой графике флэш подтормаживает (в сравнении с C++ приложениями)? Т.е. сотня спрайтов вполне могут «убить» фреймрейт, при этом нативное приложение с такими же объектами даже не поперхнется.
Это уже специфика движка флэша…
Это я понимаю, мне интересно что обуславливает эту специфику.
Я понимаю почему код может тормозить, но вот отрисовка графики… Может она совсем софтварно рисуется, даже без 2D ускорения?
Очень надеюсь, что в октябре Адоб анонсирует нечто приятное и быстрое :)
Я понимаю почему код может тормозить, но вот отрисовка графики… Может она совсем софтварно рисуется, даже без 2D ускорения?
Очень надеюсь, что в октябре Адоб анонсирует нечто приятное и быстрое :)
Вроде, собираются 3Д внедрять в следующей версии флэш плеера?..
По слухам — да.
«нативное» 3d и в 10 есть, есть даже некая аппаратная акселерация, другой момент в том, что даже тот же дроТрианглс реализован весьма криво…
Нативное 3D в десятке? Мм… Что-то мне подсказывает, что его обещали, но так и не сделали. И всякие Alternativa3D и PaperVision работают полностью софтварно.
как раз таки из-за кривости этих самых нативных 3d методов, большинство 3д движков юзают по прежнему moveTo, lineTo
зато поддерживается кулинг и УВТмэпинг
help.adobe.com/en_US/Actionscript/3.0_ProgrammingAS3/WSF24A5A75-38D6-4a44-BDC6-927A2B123E90.html
зато поддерживается кулинг и УВТмэпинг
help.adobe.com/en_US/Actionscript/3.0_ProgrammingAS3/WSF24A5A75-38D6-4a44-BDC6-927A2B123E90.html
Нет акселерации для 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. Все к чему часто обращаемся лучше сделать многоразовым, использовать заново вместо создания и удаления.
1. Меньше new.
2. Одна BitmapData на кучу Bitmap если они одинаковы.
3. cacheAsBitmap если не применяем трансформаций к объекту. Очень ускоряет фильтры.
4. opaqueBackground если не нужна прозрачность.
5. Избегать обращений к элементам массива в цикле через квадратные скобочки там, где это возможно.
6. Объект не рендериться если visible=false или он вне пределов видимой сцены. Но процессорное время на обсчет этого объекта тратиться, так что используем removeChild.
7. visible=false лучше чем alpha=0;
8. Прозрачность тормозит. Фильтры тормозят. Массивы тормозят. new тормозят.
9. Оптимизируем векторные изображения.
10. Точечная нотация в циклах тормозит. Перед циклом создаем переменную которой присваиваем длинную строку с кучей точек.
11. Все к чему часто обращаемся лучше сделать многоразовым, использовать заново вместо создания и удаления.
а про квадратные скобки для массива, пожалуйста, можно подробнее?
Я бы не стал советовать всегда юзать removeChild() вместо visible=false.
Есть куча место, когда именно visible будет работать быстрее. Особенно если вам приходится постоянно добавлять/удалять один и тот же мувик.
Есть куча место, когда именно visible будет работать быстрее. Особенно если вам приходится постоянно добавлять/удалять один и тот же мувик.
Интересно, напишите! :)
3 — разве автоматом не врубается?
5 — тоже попрошу разяснений :)
6 — если очень много скрытых интерактивных элементов (тыщи), то прозиводительность можно поднять в разы этим методом.
8 — особенно тормозят твины по прозрачности. А с массивами-то что делать? Мне нужен быстрый и надежный хаштейбл, есть такой?
От себя добавлю
а) не вешать никаких особых перерисовок на маус_мув, лучше на ентер_фрейм
б) не везде нужен фреймрейт 30, для многих приложений достаточно 15 и даже 10 — пожалейте юзера и разгрузите ему проц. Видео будет кстати работать нормально.
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
Ок. Спасибо за интерес, постараюсь сделать.
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собенно если это ентер_фрейм!
www.adobe.com/livedocs/flash/9.0/ActionscriptLangRefV3/flash/filters/BlurFilter.html
У меня еще прирост из-за того что я на стейж_ремув отписываюсь от всех лишних событий, а потом снова записываюсь на адед_ту_стейж. Такое имеет смысл делать когда есть много скрытых объектов (например за экраном), которые еще и имеют наглость чегото-то слушать. Oсобенно если это ентер_фрейм!
Хотя где-то находил что в следующих версиях языка сделают типизированные массивы.
Ну как бы они уже есть. Называются Vector.
Пишется так: Vector.Вроде как на 30% быстрее.
если fps 30 то обычно маус мув реже чем ентер фрэйм.
Плохо то, что вы украли идею игры, а статья норм
за правду не ругают :) мне кажется сама цель статьи был хитрый ПИАР :))) ну это моё мнения
Чистейший? Объяснена суть кэширования. Приведен пример на сторонние исходники для кэширования анимаций (все знали об этом классе?), объяснен принцип их работы.
Плюс ссылка на наше приложение и скрин, да.
Пиар есть, но полезной информации тут гораздо больше.
ИМХО.
Плюс ссылка на наше приложение и скрин, да.
Пиар есть, но полезной информации тут гораздо больше.
ИМХО.
Посмотрел на вашу игру...) С производительностью вы перестарались)) Бой прошел за 2 секунды, я ничего не успел рассмотреть))
>>>Приложению будет доступно Ваше имя, дата рождения, фотография, список друзей и базовая информация на странице.
Зачем? o_O
Зачем? o_O
У меня дилетанский вопрос. Как сделать плавное (без подергиваний) медленное передвижение картинки (не вектор) во флеше?
больше кадров сделать, а если используеш класс из статьи то там нужно смотрет где точка основная клипа.
я использую клас из примера www.touchmypixel.com/blog_examples/081128%20Cached%20Animations%20SpriteSheets/ — там есть возможноть кешировать по спрайтам
я использую клас из примера www.touchmypixel.com/blog_examples/081128%20Cached%20Animations%20SpriteSheets/ — там есть возможноть кешировать по спрайтам
Я обычно рисую все в битмап, а потом уже вывожу на экран, в главный битмап рисую так:
matrix.tx = sx; matrix.ty = sy; BITMAP.draw(imageBitmapData, matrix, null, BlendMode.NORMAL, null, true );
>Решение для анимированных клипов.
На практике данное решение действительно выгодно только в довольно узком диапазоне при соблюдении условий:
1. Много экземпляров одной и той же анимации, а не разных.
2. Анимация выполнена в одном таймлайне, без вложенных анимаций.
3. Анимация имеет малое число кадров (для большого числа кадров придется делать перевод в раст итерациями в разных стеках вызова, иначе флеш плеер будет подвисать на слабых системах)
И еще минусы:
1. За прирост производительности придется заплатить памятью, чем длиннее анимация и большее ее линейный размер, тем больше расходуется памяти. По сути метод делает пререндеринг всей анимации и хранит в памяти растровое изображения каждого кадра, в то время как флеш плеер рендерит только текущий кадр, удаляя из памяти остальные кадры.
2. При масштабировании всей сцены придется либо обновлять растровую карту анимаций, либо смотреть на пикселы (увеличение) или не сглаженные границы (уменьшение)
На практике данное решение действительно выгодно только в довольно узком диапазоне при соблюдении условий:
1. Много экземпляров одной и той же анимации, а не разных.
2. Анимация выполнена в одном таймлайне, без вложенных анимаций.
3. Анимация имеет малое число кадров (для большого числа кадров придется делать перевод в раст итерациями в разных стеках вызова, иначе флеш плеер будет подвисать на слабых системах)
И еще минусы:
1. За прирост производительности придется заплатить памятью, чем длиннее анимация и большее ее линейный размер, тем больше расходуется памяти. По сути метод делает пререндеринг всей анимации и хранит в памяти растровое изображения каждого кадра, в то время как флеш плеер рендерит только текущий кадр, удаляя из памяти остальные кадры.
2. При масштабировании всей сцены придется либо обновлять растровую карту анимаций, либо смотреть на пикселы (увеличение) или не сглаженные границы (уменьшение)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Производительность и оптимизация отрисовки графики во Flash