Просмотр полной версии : Флеш оптимизация (код vs анимация)
Сколько бы не работал на флеше, всегда, когда начинаю новый проект встает вопрос с каким подходом реализовать тот или иной элемент в проекте. Конечно, есть куча параметров и критериев, по которым можно определиться с подходом. Основные и главные из них - это вес флешки, загрузка проца флешкой. Если важен вес, надо максимум кодировать, если важно быстродействие - анимация. Но все гораздо сложнее...
Я сталкивался с тем, что некоторые эффекты меньше весят, если их кодить, а некоторые - если их анимировать. С циклами также: некоторые циклы оптимальней в коде, некоторые с возвратом по кадрам.
Есть ли какая-нибудь информация, обзоры и т.д. связанные с оптимизацией флеш-эффектов??? Может какие-то примеры реализованные разными подходами. Кто вообще задумывался над этим вопросом писать сюда!!! Просто хочется создать(определить) какие-то каноны по созданию определеных (самых распрастраненных) эффектов, чтобы можно было сразу знать как их реализовывать, не задумываясь о том, "насколько оптимально это будет?", "а может можно сделать лучше?".
Можно даже сделать типа эксперементальной лабараторрии на форуме, где можно будет приводить разные примеры реализованные разными подходами.
Не думайте, что эта мысль посещала только вас. Тема обсуждалась не раз. Зайдите в поиск и набирите "оптимизация".
Ага! я видел! Но тема не раскрыта! Если ее развивать, то просто предлагаю сюда выносить только тесты по работе функций, подходов и т.д.
Ага! я видел! Но тема не раскрыта! Если ее развивать, то просто предлагаю сюда выносить только тесты по работе функций, подходов и т.д.Так весь форум это и есть большая база методов и подходов. Или вы думали, что все уместится на пару страниц?
Я тему не зря назвал (код vs анимация)! Про оптимизацию кода можно говорить долго и нудно, тем более эту инфу можно найти в рунете. Когда мы оптимизируем код, думаем только о процессоре. Я же имел ввиду "золотую" середину, между весом и "сложностью" для процессора флешки.
Я думаю со мной многие согласятся, что все закодить все равно не возможно (тот самый 1%). А даже если в конкретном случае и возможно, то целесообразно ли???? Не знаю какой пример привести. Первое что приходит в голову: допустим просто надо вращать градиент, мы можем нарисовать область, залить градиентом и затвинить или закодить вращение. А можно все кодом: lineTo, beginGradientFill и т.д. еще сделать матрицу преобразования и преобразовывать этот градиент. Где-то без второго подхода не обойтись, ну а если нам нужен просто вращение градиента без всяких наворотов??? Второй подход проц думаю сожрет не слабо!
еще например: сделаем мувик в руте, обзовем, поставим координату х =100, в кадре код:
mc_mc.onEnterFrame = function(){
this._x++;
if(this._x==150) delete this.onEnterFrame;
}
сделаем тоже твином, т.е. в последнем ключевом кадре поставим координату х=150, а твин ратянем на 50 кадров.
Второй мувик будет тяжелее!!! Теперь убавим до 10 кадров, т.е.
mc_mc.onEnterFrame = function(){
this._x++;
if(this._x==110) delete this.onEnterFrame;
}
во втором случае твин надо сделать на 10 кадров, и поменять в ключевом псоледнем кадре координату мува на 110
во втором случае вес первого подхода не изменился, потому как код остался прежним, а вот второго - стал меньше весить даже чем первый.
Вот теперь можно сформулировать вопрос исходя из примера: можно ли как-то, по каким-то критериям (может по количеву кадров в твине, может по сложности кода), оценить что будет меньше весить и в тоже время минимально загружать проц????!?
В таких мелочах только сравнением.
Я думаю со мной многие согласятся, что все закодить все равно не возможно (тот самый 1%). А даже если в конкретном случае и возможно, то целесообразно ли???? Не знаю какой пример привести. Первое что приходит в голову: допустим просто надо вращать градиент, мы можем нарисовать область, залить градиентом и затвинить или закодить вращение. А можно все кодом: lineTo, beginGradientFill и т.д. еще сделать матрицу преобразования и преобразовывать этот градиент. Где-то без второго подхода не обойтись, ну а если нам нужен просто вращение градиента без всяких наворотов??? Второй подход проц думаю сожрет не слабо!
Это не оптимизация, а разные реализации.
Сейчас приведу пример. Делаю все в Flash 8, размер 800 на 600, fps 30, публикация по 8-ой плеер AS2.
Рисую черный квадрат, без outline, координаты x=0, y=0
1. Размер квадрата w=1, h=1. Вес swf 79 байта.
2. Размер квадрата w=5, h=5. Вес swf 82 байта.
3. Размер квадрата w=10, h=10. Вес swf 83 байта.
4. Размер квадрата w=20, h=20. Вес swf 84 байта.
5. Размер квадрата w=30, h=30. Вес swf 86 байта.
6. Размер квадрата w=100, h=100. Вес swf 87 байта.
Все! тема закрыта! смысл мусолить такие вещи?? я привел пример - не надо на него приводить еще один пример. Это все равно что отвечать вопросом на вопрос.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.