Comments 38
Я один безрезультатно кликнул на кнопки «Play 1» и «Play 2»? :)
Ох… :) Ну вот тогда, восстанавливайте душевное равновесие: goo.gl/sfZcy
Не один! Я тоже вклубе :)
Нет.
Меня терзали сомнения )) но на Плай 1 я таки жамкнул )
У вас здесь ошибка в участке "
width: 300px"TweenMax.to($('#ufo'), 2, {width: 300px}, ease: Linear.easeNone)</blockquote>
Канвас это конечно хорошо, поболоватся можно и нужно, но в каких-то более менее вменяемых проэктах — кроме как нарисовать график — он, к сожалению мало применим из-за свей медлительности :(
Во-первых, в топике нету ни слова про канвас.
Во-вторых, он медлителен только если бездумно перерисовывать каждый кадр всё, что есть на поле. На данный момент html5-canvas коммерчески-приемлим.
Во-вторых, он медлителен только если бездумно перерисовывать каждый кадр всё, что есть на поле. На данный момент html5-canvas коммерчески-приемлим.
А где вы тут canvas увидели? На всякий случай, автор обычные dom-элементы анимирует.
К слову о canvas, он далеко не для отрисовки графиков предназначен, благо здесь и без него инструментов хватает.
К слову о canvas, он далеко не для отрисовки графиков предназначен, благо здесь и без него инструментов хватает.
Вы просто не умеете его готовить ©
Да, да, не разглядел с самого начала, приношу извинения, а по поводу канваса — значит мне не попадались годные проекты.
UFO just landed and posted this here
Прикольный баг: при перемещении объекта background-анимация сбрасывается в начальное значение, в итоге габаритные огни «глючат». Когда тарелка стоит на месте — все ок.
наконец-то)
по большей части нужно только для полной кроссплатформенности, да и то — что-то есть сомнения в полной адекватности и стабильности.
Лично мое мнение, что лучше стараться анимировать в CSS3 Animate. Причины:
1) CSS в данном случае работает как макроязык анимации.(тем не менее для сложной анимации можно и JS присобачить, как контроллер точек выполнения), что дает определенный порядок при проектировании.
2) JavaScript у нас однопоточный, и в современных сайтах у него другой работы полно, а не только анимацию строгать. А так, CSS не мешает JavaScript-у работать
3) Зная, как иногда народ увлекается такими анимашками и по нескольку штук их пичкают, грузить это будет неприятно.(если кто будет говорить, про быстрые браузеры и мощные компы — то вспомните, что у нынешнего пользователя, обычно открыто по двадцать вкладок. И в каждом такая дрянь будет работать, если правда не используется requestAnimationFrame)
4) По наблюдениям, скажу честно. Когда клиенты видят эти анимации в IE и видят лаги, обвиняют они разработчика сайта в тормозах, а не старый свой браузер. В таком случае лучше уж для IE засунуть простую gif-ку. Пусть некрасиво, зато не тормозит.
5) CSS3 Animation (и transform) в chrome и firefox (в opera только с 12-ой), все правила работают с частичным использованием gpu ускорения. А вот с работой DOM модели, только CPU загрузите.
6) Можно впринципе заюзать и canvas. Как тут правильно писали — если правильно с ним работать, можно отличные выжать результаты.
7) А для графиков — как тут кто-то писал, я бы вообще предлагал посмотреть в сторону SVG.
В общем это лично мое мнение, которое построилось из личного опыта.
К чему я это написал? Я не уверен в поддержке этих библиотек. Не уверен в стабильной скорости анимации, основанной на данной библиотеке, в перегруженных всякой чепухой страницах И поэтому в коммерческих проектах не рискнул бы использовать эту библиотеку, и выше я описал почему. Хотя позднее, возможно, свою нишу эта библиотека найдет.
Лично мое мнение, что лучше стараться анимировать в CSS3 Animate. Причины:
1) CSS в данном случае работает как макроязык анимации.(тем не менее для сложной анимации можно и JS присобачить, как контроллер точек выполнения), что дает определенный порядок при проектировании.
2) JavaScript у нас однопоточный, и в современных сайтах у него другой работы полно, а не только анимацию строгать. А так, CSS не мешает JavaScript-у работать
3) Зная, как иногда народ увлекается такими анимашками и по нескольку штук их пичкают, грузить это будет неприятно.(если кто будет говорить, про быстрые браузеры и мощные компы — то вспомните, что у нынешнего пользователя, обычно открыто по двадцать вкладок. И в каждом такая дрянь будет работать, если правда не используется requestAnimationFrame)
4) По наблюдениям, скажу честно. Когда клиенты видят эти анимации в IE и видят лаги, обвиняют они разработчика сайта в тормозах, а не старый свой браузер. В таком случае лучше уж для IE засунуть простую gif-ку. Пусть некрасиво, зато не тормозит.
5) CSS3 Animation (и transform) в chrome и firefox (в opera только с 12-ой), все правила работают с частичным использованием gpu ускорения. А вот с работой DOM модели, только CPU загрузите.
6) Можно впринципе заюзать и canvas. Как тут правильно писали — если правильно с ним работать, можно отличные выжать результаты.
7) А для графиков — как тут кто-то писал, я бы вообще предлагал посмотреть в сторону SVG.
В общем это лично мое мнение, которое построилось из личного опыта.
К чему я это написал? Я не уверен в поддержке этих библиотек. Не уверен в стабильной скорости анимации, основанной на данной библиотеке, в перегруженных всякой чепухой страницах И поэтому в коммерческих проектах не рискнул бы использовать эту библиотеку, и выше я описал почему. Хотя позднее, возможно, свою нишу эта библиотека найдет.
Скорость анимации GS значительно превосходит другие JS библиотеки:
habrahabr.ru/post/144208/#comment_4839766
www.greensock.com/js/speed.html
habrahabr.ru/post/144208/#comment_4839766
www.greensock.com/js/speed.html
я ни слова не сказал про другие JS библиотеки. Я сравнил с CSS. И сравнил не в одиночном контексте, где анимации не будут мешать другие скрипты, а в проектах, где помимо анимации, есть еще куча всяких грузящих элементов.
1. CSS-анимации выполняются в том же потоке, что и JS. Т.е. если завис JS, то CSS-анимации тоже зависнут
2. CSS-анимации не обязательно быстрее, чем изменение свойств через DOM
3. Период запуска таймера в неактивной вкладке во всех современных браузерах уменьшается с 4-20мс до 1000 мс, так что они практически не будут грузить при работе в закрытой вкладке.
2. CSS-анимации не обязательно быстрее, чем изменение свойств через DOM
3. Период запуска таймера в неактивной вкладке во всех современных браузерах уменьшается с 4-20мс до 1000 мс, так что они практически не будут грузить при работе в закрытой вкладке.
давайте возьмем в пример работу google chrome.
1) В случае если виснет, это понятно — т.к. браузер ждет ответа от скрипта. Это логично.
2) CSS — это по факту тоже изменение DOM модели. Но только во первых, она использует не V8 движок, а webkit, а он по факту работает с отрендеренной моделью(что логично), что уже само по себе быстрее.
Можно заметить что само свойство ноды не меняется до окончания подблока анимации, но при этом визуальная часть изменяется. И кстати значения getComputedStyle тоже. В хроме есть еще и диспетчет задач, где отлично показывается, где, чья память используется. При CSS анимации — JS не задействуется вообще.
Хотя есть и вправду одно исключение. Зависит от простоты вычисления новых координат, и как они вычисляются. Есть разработчики браузера сделали «абы как», то тут уже другой разговор.
3) 3 пункт если вдаться в подробности, режет частично 2. Придется синхронизировать время. Одно дело когда известны промежутки времени, соответственно дельту X и дельту Y можно заранее просчитать. А вот если время исполнения плавающее — это совсем другая ситуация. Синхронизировать можно — но это еще одна, хоть и небольшая, но все-таки нагрузка. Но опять же все зависит от реализации алгоритмов в движках браузеров. Это к теме оптимизации расчета об]ектов в каждом «кадре»
4) Я может неправильно выразился, но я имел ввиду не более быструю анимацию, а более легковесную по ресурсопотреблению, из вариантов, которые мы обсуждаем.
5) Предлагаю трезво спор на эту тему не продолжать. Тема изъезженная. Это долго и тянет на отдельный пост.
1) В случае если виснет, это понятно — т.к. браузер ждет ответа от скрипта. Это логично.
2) CSS — это по факту тоже изменение DOM модели. Но только во первых, она использует не V8 движок, а webkit, а он по факту работает с отрендеренной моделью(что логично), что уже само по себе быстрее.
Можно заметить что само свойство ноды не меняется до окончания подблока анимации, но при этом визуальная часть изменяется. И кстати значения getComputedStyle тоже. В хроме есть еще и диспетчет задач, где отлично показывается, где, чья память используется. При CSS анимации — JS не задействуется вообще.
Хотя есть и вправду одно исключение. Зависит от простоты вычисления новых координат, и как они вычисляются. Есть разработчики браузера сделали «абы как», то тут уже другой разговор.
3) 3 пункт если вдаться в подробности, режет частично 2. Придется синхронизировать время. Одно дело когда известны промежутки времени, соответственно дельту X и дельту Y можно заранее просчитать. А вот если время исполнения плавающее — это совсем другая ситуация. Синхронизировать можно — но это еще одна, хоть и небольшая, но все-таки нагрузка. Но опять же все зависит от реализации алгоритмов в движках браузеров. Это к теме оптимизации расчета об]ектов в каждом «кадре»
4) Я может неправильно выразился, но я имел ввиду не более быструю анимацию, а более легковесную по ресурсопотреблению, из вариантов, которые мы обсуждаем.
5) Предлагаю трезво спор на эту тему не продолжать. Тема изъезженная. Это долго и тянет на отдельный пост.
Стоило убивать флэш, чтобы в настоящем затрачивать подобные усилия и достигать таких результатов? Вопрос риторический…
TweenMax.to( $('#sample'), 1, {value: 300} ); // за 2 секунды значение станет равно 300
Почему две секунды? В параметрах одна же. Прикол в том, что по ощущению это длится действительно две секунды.
Не понимать :'(
Почему две секунды? В параметрах одна же. Прикол в том, что по ощущению это длится действительно две секунды.
Не понимать :'(
Ивенты поддерживаются? Можно навесить хандлер на элемент графики?
Я не силен в JS и CSS, поэтому если надо, то беру какие-нить интересные готовые решения (типа этого) и переделываю под свои нужды.
Поэтому (может быть и тупой) вопрос: сравнительно $fx() (откуда была взята идея примера) Ваш способ чем хорош/плох?
Я особо не всматривался, но визуально что там что тут работает примерно одинаково все.
Спасибо
Поэтому (может быть и тупой) вопрос: сравнительно $fx() (откуда была взята идея примера) Ваш способ чем хорош/плох?
Я особо не всматривался, но визуально что там что тут работает примерно одинаково все.
Спасибо
Удалите третий кадр в спрайте, анимация тарелки не будет дергаться.
Вот тут вроде ничего не дергается с тем же спрайтом.
Sign up to leave a comment.
Greensock: анимация на JavaScript