#actionscript-3 #air #bitmap #vector-graphics #rasterize
#actionscript-3 #air #растровое изображение #векторная графика #растрировать
Вопрос:
я разработал кроссплатформенное приложение AIR, которое серьезно отстает в производительности на мобильных устройствах из-за анимации / использования векторной графики вместо растровых ресурсов. использование cacheAsBitmapMatrix / cacheAsBitmap лучше, когда и где назначено соответствующим образом, но все же не так быстро, как использование ресурсов bitmap.
я попытался с помощью BitmapData.draw () преобразовать векторную графику в растровый объект во время выполнения и вместо этого анимировать растровый объект, но это выполняется примерно так же хорошо, как (или, может быть, даже точно так же, как) простое кэширование векторной графики в виде растрового изображения.
Пользовательский интерфейс Flash Professional 5.5 теперь имеет возможность конвертировать векторную графику в растровые ресурсы, но возможно ли это сделать во время выполнения? возможно ли иметь реальную процедуру Rasterize () для преобразования программно нарисованной векторной графики и, возможно, даже редактируемого текста в растровые изображения во время выполнения для оптимальной производительности анимации, особенно на мобильных устройствах?
Ответ №1:
Когда вы говорите, что пытались анимировать растровое изображение, я надеюсь, вы не имели в виду, что вы поворачивали / изменяли размер растрового изображения, поскольку это медленный процесс.
Может быть, у вас есть движок, который во время загрузки вашей игры создает для вас лист спрайтов на основе кадров в видеоролике (если есть анимация). Тогда на них можно было бы ссылаться BitmapData.copyPixels() .
Это было бы просто:
- Создайте объект BitmapData.
- Нарисуйте каждый кадр временной шкалы MovieClips на BitmapData, как если бы вы вручную использовали лист спрайтов.
- Сохраните BitmapData в ассоциативный массив для удобного доступа позже, например
sheets["zombie1"]
Вы даже можете повернуть свой объект в цикле for и нарисовать повернутый объект на листе.
Тогда у вашего SheetObject были бы просто методы для загрузки части ранее определенного листа и его отображения.
Все ли это на правильном пути ..?
Комментарии:
1. Если все они хранятся в массиве, вам действительно не нужно помещать их в таблицу спрайтов. Вы можете просто получить к ним доступ из массива, т.е. animations[«zombie_walk»] = zombieWalkFrames — ваш массив кадров для этой анимации. Обычно я использую листы спрайтов только в том случае, если контент был создан таким образом. Если в качестве исходного кода используются векторные movieclips, лучше всего просто использовать массивы и управлять ими таким образом.
2. я не делаю никаких фреймовых сценариев. это вся программно созданная векторная графика (drawing API) и программа Tweener для анимации. да, я поворачиваю и масштабирую графику — например, на экране есть квадрат. прикосновение к квадрату заставляет его парить над сценой, слегка увеличивая его масштаб и смещая тень. я понимаю, что добавление фильтров к векторной графике автоматически кэширует графику в виде растрового изображения. предполагается ли, что масштабирование / поворот векторной графики (без фильтров) выполняется быстрее, чем масштабирование / поворот растровых изображений? кроме того, я публикую в AIR 2.5 и еще не пробовал AIR 2.6
3. Множество объектов с примененными фильтрами, которые перемещаются, меняют форму, вращаются или действительно делают что-либо еще, кроме статичности, будут очень сильно влиять на производительность — независимо от того, к какому типу объектов они относятся (растровое изображение / вектор).
4. В принципе, вы можете предварительно выполнить поворот / масштабирование, если вам нужна скорость. copyPixels — это маршрут, по которому вы хотите пройти в blitting, это быстрее, чем рисовать. Как говорит Марти, невозможно обойти снижение производительности, если вы выполняете масштабирование / поворот «на лету». Имейте в виду, что bitmapCaching фактически замедляет работу, если вы масштабируете / поворачиваете векторы. В этом случае вам будет лучше без растрового кеширования. Потому что это будет кэширование нового масштабирования / поворота каждого кадра. Также имейте в виду, что если вы хотите поворачивать / масштабировать растровое изображение на лету, оно будет немного неровным по сравнению с векторным.