Наиболее оптимальный способ вращения битмапа

[nubideus]

mikhailk, и че прям не лагает?

[mikhailk]

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

[elder_Nosferatu]

Если трансформация заключается в обычном myDisplayObject.rotation = newAngleValue, то никакие твинеры не спасут ибо как не крути а они сложнее обычной подписки на Event.ENTER_FRAME. А значит и производительности эти твинеры не прибавят.

Если на древнем железе есть визуальные лаги, то спасти может только пререндеринг, но такой подход скушает много памяти (картинка то габаритная). Но если колесо изображено схематически и может быть поделено на несколько визуально идентичных секторов, то можно сократить расход памяти, отрисовав несколько положений колеса не в диапазоне 0..360 градусов, а в 0..360/n градусов, где n - количество секторов.

[Zebestov]

elder_Nosferatu, и это все не принесет нам ни грамма выигрыша. Если кусков не 4 (по 90 градусов), то мы просто превратим отрисовку двух треугольников в отрисовку два-по-360/n треугольников. Говоря другими словами, мы сделаем пререндер сектора, потратим память (а колесо вращается мееедленно, памяти уйдет мнооого), намучаемся со стыковкой швов и в конечном счете проиграем даже в скорости.

В данном случае смещение баланса в сторону избыточной информации не принесет прироста производительности.

[in4core]

Если трансформация заключается в обычном myDisplayObject.rotation = newAngleValue, то никакие твинеры не спасут ибо как не крути а они сложнее обычной подписки на Event.ENTER_FRAME. А значит и производительности эти твинеры не прибавят.

Проверно на личном опыте - твинМакс + блитМаск дает прирост чуть ли не в 200% против интер_фрейм при работе с битмапами больших размеров. Или большими спрайтами с частями битмап, причем самой простейшей анимацией х++, y++

[elder_Nosferatu]

@Zebestov
Я писал об отрисовке всего колеса, а не его сектора. А значит и склеивать ничего не прийдется. О секторах я завел разговор только потому, что если, к примеру, колесо разделено спицами на 5 72-градусных идентичных секторов, то поворот на 72 градуса будет выглядеть также, как и на 144 и на 216 и на 360 градусов, а поворот на 5 градусов такой же, как и на 77 и на 149... градусов. А это значит, что нет смысла рисовать вид колеса в положениях от 0 до 360, достаточно будет от 0 до 72

[Zebestov]

elder_Nosferatu, понял. Но тогда памяти действительно уйдет многовато — все колесо хранить.

[nubideus]

elder_Nosferatu, а чем это поможет если и там и там нужно рисовать картинку с поворотом?

[mikhailk]

Проверно на личном опыте - твинМакс + блитМаск дает прирост чуть ли не в 200% против интер_фрейм при работе с битмапами больших размеров. Или большими спрайтами с частями битмап, причем самой простейшей анимацией х++, y++

При анимации смещения, наверняка, так и есть.
При анимации вращения вариант с трианглами оказался визуально производительнее.

Если на древнем железе есть визуальные лаги, то спасти может только пререндеринг, но такой подход скушает много памяти (картинка то габаритная).

Да, естественно.
Но в силу ряда причин пререндеринг может быть невозможен.

Например, на колесо наносятся дополнительные маркеры, перекрашиваются сектора и все такое прямо во время вращения. Модифицировать одну битмапдату на лету проблем нет. Пересобрать все 360 битмапдат - это уже затратная операция.

[elder_Nosferatu]

@nubideus
Погуглите значение слова "пререндеринг"
Если перед анимированием закешировать разные состряния, то вместо их отрисовки по нужде можно использовать готовые состояния из кеша.