программная анимация

[taha]

melky,
во всех броузеров работало отлично.. просто моя позиция если можно исправить что-то, то лучше это сделать...

ещё раз спасибо всем.. анимация стала работать в разы быстрее даже на, вечно жрущем память, firefox'е

жалко только что IE<9

transition: transform 0.4s linear;
box-shadow: 0px 2px 2px rgba(0,0,0,0.7);
border-radius: 5px;

понимать отказывается, а при подключении PIE.htc вообще как-то странно себя ведёт, но срать на его пользователей.. основная часть анимации меню на js, им этого будет достаточно

[nerv_]

nerv_, ваш способ медленнее и больше памяти жрёт.

не сочтите за труд, скажите почему? Дело в обращении к объекту или setTimeout?

[devote]

не сочтите за труд, скажите почему? Дело в обращении к объекту или setTimeout?

Да мне тоже хотелось бы выслушать позицию на эту тему...

[taha]

здесь в теме всё описано, все мои предположения, сомнения, и опровержения со стороны знающих людей

читайте сначала этой темы

про скоп замыкания и тд.

Советы по оптимизации

Большое количество таймеров сильно нагружают процессор.
Если вы хотите запустить несколько анимаций одновременно, например, показать много падающих снежинок, то управляйте ими с помощью одного таймера.

Дело в том, что каждый таймер вызывает перерисовку. Поэтому браузер работает гораздо эффективней, если для всех анимаций приходится делать одну перерисовку.

Фреймворки обычно используют один setInterval и запускают все кадры в заданном интервале.
Помогайте браузеру в отрисовке
Браузер управляет отрисовкой дерева и элементы зависят друг от друга.

Если анимируемый элемент лежит глубоко в DOM, то другие элементы зависят от его размеров и позиции. Даже если анимация не касается их, браузер все равно делает лишние расчёты.

Для того, чтобы анимация меньше расходовала ресурсы процессора(и была плавнее), не анимируйте элемент, находящийся глубоко в DOM.

Вместо этого:

Для начала, удалите анимируемый элемент из DOM и прикрепите его непосредственно к BODY. Вам, возможно придется использовать position: absolute и выставить координаты.
Анимируйте элемент.
Верните его обратно в DOM.

Эта хитрость поможет выполнять сложные анимации и при этом экономить ресурсы процессора.

Если JavaScript-анимация слишком медленно работает на смартфонах и планшетах, то, возможно, стоит заменить ее CSS-переходами.

[taha]

анимация и процессор))

[trikadin]

не сочтите за труд, скажите почему? Дело в обращении к объекту или setTimeout?

Потому что setInterval - это нативное повторение через определённый промежуток. Оно по умолчанию быстрее всего, что вы можете сделать в исполняемом коде JS. А в вашем варианте такты процессора расходуются ещё и на постоянное добавление setTimeout. Я, наверное, плохо объясняю, но суть в этом.

Вторая причина - так как setTimeout вложенный, то для поиска локальных переменных интерпретатору придётся каждый раз подниматься всё на большее кол-во скопов.

[Kolyaj]

Вторая причина - так как setTimeout вложенный, то для поиска локальных переменных интерпретатору придётся каждый раз подниматься всё на большее кол-во скопов.

Какая глупость.

В целом про setTimeout vs setInterval http://alljs.ru/articles/timeout/setinterval

[devote]

Что меня поражает, то что люди где-то что-то вычитают, и потом всем подряд советую при этом выкрикивая что, что-то там не рекомендуется. Насчет скопов я не соглашусь, наиполнейший бред, никаких скопов там не собирается. Проверено не однократно, загрузка ЦП да чуть выше у setTimeout по известной причине. Так как setTimeout более корректнее работает с задержками, пожирание памяти никакой нет... Если считаете иначе, пример в студию...

От себя добавлю, анимацию через setTimeout делаю и не имею проблем, протестировано временем и жестокими тестирования. Запустите:

setTimeout(function blah(){
    setTimeout(blah, 1);
}, 1);

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

Хватит людям впаривать в мозг всякий бред о ресурсах и т.д. ИМХО

[taha]

хмммммм... и все источники противоречат друг другу...

и всётаки хотелось бы больее детальных поянений.. совершенно естествеенно, что мини-турбини функции с одим действием работают примерно одинаково, но если будет больше локальных переменных во внешней функции и их будет много в локальной, ну или они хотябы будут(в примерах статьи их нет)??? что будет??

допустим у меня с итервалом работает быстрее чем с таймаутом..

как люитель асма я немогу этого понять... использовать стек отработавшей функции - как то не очень хорошо.. но раз уж в JS есть замыкания то всёже хотелось бы пояснений... нигде про это ничего не сказано, поэтому я и поднял эту тему.. про скопы, локальные переменные и тд

[taha]

я конечно понимаю, что кому то всё равно, но я предпочитаю делать свои коды наиболее оптимальными и читабельными, поэтому мне интересна эта тема с setTimeout'ами и скопами.. не знаю в какое мере они создаются, в большей степени или в той какой вы говорите, но всёже создаются.. вункция работает рекурсивно и вызов следующей итерации не дожидается завершения предыдущей, в отличии от интервала


скачек нагрузки проца при каждой анимации в firefox я наблюдаю на системном мониторе.. см картинку выше