Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
Симпатичные отработки. Да и колбэк есть.
Почему деградацию не встроили в плагин? Делали же до этого все анимации «по-старому» и не жаловались на скорость… Непонятно.
А вот еще один плагин — jquery.transition.js:
Upgrade jQuery's .animate() method to use CSS3 Transitions in modern browsers.
У меня в примерах в Safari всё моргает, почему-то. В Firefox такого не наблюдается
Не очень понимаю, почему transition делает анимации сверхплавными. CSS Animation с 3D-ускорением ещё делает анимации быстрее, но обычный transition на текущих браузерах работает с той же скоростью.
Самое главное, что transition и CSS Animation добавили, чтобы мы не указывали анимацию в JavaScript, потому что тогда мы смешиваем CSS и JS-код. То есть в JS мы должны просто добавлять/убирать класс состояния, а то, как какое-то состояние выглядит и как определены переходы между состояниями указываем в CSS.
Поэтому этот плагин кажется мне странным. Хотите указывать анимации в transition — используйте CSS, а не JS.
Самое главное, что transition и CSS Animation добавили, чтобы мы не указывали анимацию в JavaScript, потому что тогда мы смешиваем CSS и JS-код. То есть в JS мы должны просто добавлять/убирать класс состояния, а то, как какое-то состояние выглядит и как определены переходы между состояниями указываем в CSS.
Поэтому этот плагин кажется мне странным. Хотите указывать анимации в transition — используйте CSS, а не JS.
Этот плагин позволяет использовать CSS transition, но добавляет немного сахара в виде поддержки существующего синтаксиса jQuery, что позволяет ничего не менять ничего в существующих приложениях.
Так какой смысл использовать transition?
Имеется в виде, какой смысл использовать CSS Transition из JavaScript.
Вы имеете в виду, что лучше всё заранее описать в CSS файлах, а из JS только добавлять и удалять классы у элементов? Да, наверняка в некоторых случаях так будет проще и код будет более легко поддерживаем. Но существуют случаи, когда хочется использовать те же обратные вызовы, для запуска, например, какой-то другой анимации, или даже когда хочется запустить эффект при выходе указателя мыши с территории элемента.
Тогда используйте обычные jQuery-анимации. Использование transition не даёт никаких видимых преимуществ по скорости анимации.
Анимации jQuery жутко оптимизированные, дальше их оптимизировать не получиться, поэтому анимация в transition не может быть существеннее быстрее или плавнее.
Исключение только если у вас CSS-анимации перемешиваются с JS-анимация — но это решается тем, чтобы использовать requestAnimationFrame в JS-анимация.
Так же в некоторых браузерах аппаратно ускоряются анимации, которые заданы через CSS Animation и когда применяются 3D-трансформации. Но опять же, это не имеет никакого отношения к transition.
Так что transition рисуется так же плавно, как и jQuery-анимации.
Анимации jQuery жутко оптимизированные, дальше их оптимизировать не получиться, поэтому анимация в transition не может быть существеннее быстрее или плавнее.
Исключение только если у вас CSS-анимации перемешиваются с JS-анимация — но это решается тем, чтобы использовать requestAnimationFrame в JS-анимация.
Так же в некоторых браузерах аппаратно ускоряются анимации, которые заданы через CSS Animation и когда применяются 3D-трансформации. Но опять же, это не имеет никакого отношения к transition.
Так что transition рисуется так же плавно, как и jQuery-анимации.
Да, я рассматривал ситуацию только на больших компьютерах, а не на планшетах, так что я могу ошибаться. Но как я понимаю, аппаратное ускорение в iOS применяется для CSS Animation, а не transition. У вас есть ссылка на конкретное исследование, почему анимации через CSS работают быстрее на iOS и Android?
ОК, тогда повторюсь, что в статье надо написать, что плагин для быстрый анимации на iOS, а не для быстрой анимации везде.
И они решаются с помощью transition? Да ладно, transition не решает проблему перерисовок и перерассчёта стилей. JS-анимация тормозит только там, где тормозит обычный setTimeout.
Не верю, что на нетбуках тормозит setTimeout (то есть transition решит проблем). Нетбуки тормозят, так как им трудно быстро перерисовывать большие области экрана.
Не верю, что на нетбуках тормозит setTimeout (то есть transition решит проблем). Нетбуки тормозят, так как им трудно быстро перерисовывать большие области экрана.
ваша фраза выглядит как «в статье про C надо писать что он лишь под слабые системы, а не для всех систем»
Я говорю лишь, что transition не делает анимацию плавнее, он только решает медленный setTimeout в iOS. Если анимация требует перерисовки большой области экрана (что чаще случается), то она будет тормозить одинаково, как на transition, так и на JS. Такие тормоза решаются совсем другими способами.
Использование же transition при вызове из jQuery для обычных сайтов не сделает анимацию плавнее, а только создаст проблемы при разработке из-за отсутствия нормальный easing-функция и отсётствия поддержки всех свойств у easing.
Использование же transition при вызове из jQuery для обычных сайтов не сделает анимацию плавнее, а только создаст проблемы при разработке из-за отсутствия нормальный easing-функция и отсётствия поддержки всех свойств у easing.
Гм, я вижу себе это так. Когда мы задаем анимацию через css — код выполняет допустим скомпилированный chrome, а машинный код вроде как самый шустрый. При этом еще и аппаратное ускорение юзается. В то же время js делает анимацию покадрово, а сам js это байткод, при этом аппаратного ускорения нету. А перерисовка большой области с использованием аппаратного ускорения вроде как должно быть многократно быстрее. Поправьте если не прав.
Само собой любая анимация рисуется покадрово (см. requestAnimationFrame). Скорость выполнения анимации = время работы таймера изменения свойств + время пересчёта вёрстки + время перерисовки страницы.
Аппаратное ускорение анимации ускоряет перерисовку страницы. Но перерисовка страницы одинакова как для CSS-анимаций, так и для JS-анимаций. Тем более, что аппаратное ускорение включается только если есть 3D-трансформации (так как есть определённые сайд-эффекты).
Что ускоряется при использовании CSS-анимаций, так это запуск таймера, подсчёт времени и вызов изменений свойств. Но на обычных компьютерах это время просто незаметно (я очень часто использую CSS-анимацию и пробовал переписывать тяжёлую анимацию с JS на CSS). На телефонах видимо из-за особенностей работы JS ВМ setTimout сильно тормозит (я думаю, что просто в iOS сильно увеличили минимальный период setTimeout).
Аппаратное ускорение анимации ускоряет перерисовку страницы. Но перерисовка страницы одинакова как для CSS-анимаций, так и для JS-анимаций. Тем более, что аппаратное ускорение включается только если есть 3D-трансформации (так как есть определённые сайд-эффекты).
Что ускоряется при использовании CSS-анимаций, так это запуск таймера, подсчёт времени и вызов изменений свойств. Но на обычных компьютерах это время просто незаметно (я очень часто использую CSS-анимацию и пробовал переписывать тяжёлую анимацию с JS на CSS). На телефонах видимо из-за особенностей работы JS ВМ setTimout сильно тормозит (я думаю, что просто в iOS сильно увеличили минимальный период setTimeout).
В любом случае, это говорит лишь об оптимизиации браузера iOS (точнее о тормозах JS-анимация там, так как из-за другой реализации многозадачности в Android тормозов с JS-анимацией нет).
Так что и надо говорить, что этот плагин только для разработчиков мобильных сайтов.
И при том
Так что и надо говорить, что этот плагин только для разработчиков мобильных сайтов.
И при том
Но опять же, вот тут stickmanventures.com/labs/demo/spinning-gears-Chrome-preserve-3d/ говориться только об ускорении анимации через аппаратное 3D.
Смысл в том, что, например, если Вы хотите выполнить анимацию background image по позиции x, то в одних браузерах сработает css transitions, а в других $.animate('backgroundPositionX', ...).
Таким образом, все равно придется JS.
Также см. stackoverflow.com/a/8175460/335304
Таким образом, все равно придется JS.
Также см. stackoverflow.com/a/8175460/335304
Если ничего не менять, ничего и не изменится. Синтаксис старый, анимации старые, приложения существующие. В чем смысл-то?
Разница — огромна.
На одном из сайтов, что я делал, есть фоновая анимация — большие полупрозрачные треугльники вращаясь плавно плавают в случайные стороны, в случаном порядке, со случайной скоростью в случайном количестве.
Пока для этого использовался animate — хром (да и любые браузеры) сходили с ума, процессор сжирало с неистовой силой.
Попробовал перевести на transit — нугрузка упала в 10 раз
На одном из сайтов, что я делал, есть фоновая анимация — большие полупрозрачные треугльники вращаясь плавно плавают в случайные стороны, в случаном порядке, со случайной скоростью в случайном количестве.
Пока для этого использовался animate — хром (да и любые браузеры) сходили с ума, процессор сжирало с неистовой силой.
Попробовал перевести на transit — нугрузка упала в 10 раз
Ну и главная проблема transition — нельзя указать все easing-функции (ил разные easing-функции для разных CSS-свойств). См., например, примеры easings.net/
Плюс transition работает не для всех CSS свойств. Например, 3D transform в Mozilla не анимируется (тут надо использовать или CSS Animation или делать анимацию из JS с помощью github.com/sproutcore/TransformJS ).
Я пробовал писать библиотеку (без всяких jQuery), которая бы в новых браузерах делала анимацию присваиванием класса и CSS transition, а в старых — анимировала вручную по таймеру. В итоге получилось, что у меня и в Опере, и в Хроме CSS анимация хуже, глючнее и дерганней, чем яваскриптовая.
Идея была примерно такая: вызывать что-то вроде animateNode(node, { from: 'css-class1', to: 'css-class2', onFinish: function(){} }). А стили для анимации хранились бы в CSS, а не в JS коде, как это делается при использовании jQuery (что идеологически неправильно). В новых браузерах просто меняется класс, в старых запускается таймер, в совсем старых типа ИЕ6 анимация отключается, чтобы не тормозить браузер.
Итог, на сегодняшний день этот подход только увеличивает тяжесть яваскриптового кода, не давая никаких выгод, по крайней мере на десктопе.
И да, здорово раздражает тот факт, что в отсталом w3c DOM нельзя получить примененные к элементу CSS-селекторы и стили (чтобы составить список для анимации). То есть, имея в стилях .some-class { color: red; } и элемент с class=«some-class», мы не можем яваскриптом получить исходное CSS правило. Также, мы не можем прочитать из CSSStyle неподдерживаемые браузером стили. Это радикально осложняет написание подобного скрипта.
Идея была примерно такая: вызывать что-то вроде animateNode(node, { from: 'css-class1', to: 'css-class2', onFinish: function(){} }). А стили для анимации хранились бы в CSS, а не в JS коде, как это делается при использовании jQuery (что идеологически неправильно). В новых браузерах просто меняется класс, в старых запускается таймер, в совсем старых типа ИЕ6 анимация отключается, чтобы не тормозить браузер.
Итог, на сегодняшний день этот подход только увеличивает тяжесть яваскриптового кода, не давая никаких выгод, по крайней мере на десктопе.
И да, здорово раздражает тот факт, что в отсталом w3c DOM нельзя получить примененные к элементу CSS-селекторы и стили (чтобы составить список для анимации). То есть, имея в стилях .some-class { color: red; } и элемент с class=«some-class», мы не можем яваскриптом получить исходное CSS правило. Также, мы не можем прочитать из CSSStyle неподдерживаемые браузером стили. Это радикально осложняет написание подобного скрипта.
неплохой плагин даже учитывая что он неофициальный ))
Transit uses jQuery’s effect queue by default, exactly like $.fn.animate. This means that transitions will never run in parallel.
Только вот в .animate() это можно выключить флагом специальным, а в этом плагине, похоже, никак.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сверхплавные трансформации для jQuery