Анимация листа со спрайтами посредством steps()

[@Mithgol]

Логотип Impending — крутая штука: PNG 6370×130 пикселов, почти полсотни кадров. Занимает 263 513 байтов.

[@nayjest]

Ого, КАК они его так сжали? Насколько я знаю, всякие там PNGcrush'и не дают такого хорошего результата

[@magic4x]

Это тот случай когда надо пробовать. Пнг жмется хорошо, иногда удивительно хорошо. Я всегда сначала сохраняю в пнг и только потом перебираю остальные варианты.
Хотя если бы ко мне пришли с просьбой анимировать картинку в 6к я бы сначала дал в глаз, а потом разбирался.

[@deerua]

jsfiddle.net/HHXfG/1/

[@fatal]

Этот пример не работает в Опере почему-то.

[@Mithgol]

Потому, что соответствующий фрагмент CSS-кода в файле http://impending.com/wp-content/themes/impending/style.css выглядит вот так:

#logoanim {
	background: url("images/meteor.png") 0px 0px no-repeat;
	width: 130px;
	height: 130px;
	position: absolute;
	left: 666px;
	top: 37px;
	-webkit-animation: logoAnim 2s steps(47, end) infinite;
	-moz-animation: logoAnim 2s steps(47, end) infinite;
	-ms-animation: logoAnim 2s steps(47, end) infinite;
}

Нетрудно видеть, что с префиксами «-webkit-», «-moz-» и «-ms-» код «animation» способен работать только в WebKit (Apple Safari, Google Chrome), в Mozilla Firefox и в Microsoft Internet Explorer соответственно.

Про браузер Opera позабыли.

Впрочем, не так уж это и удивительно. По сведениям caniuse.com, поддержка «-o-animation» появилась в предпоследней версии (Opera 12), а поддержка «animation» — в последней (Opera 12.1). Возможно, создатели Impending просто не успели учесть это.

(Хотя это не извиняет разработчика, воздержавшегося от записи безпрефиксной версии «animation» после браузеропрефиксных версий.)

[@Mithgol]

Автор первоисточника пишет “the only problem is that it always starts from the beginning and makes it look jumpy”, но я не вижу, каким образом это проблема. Закольцовывать, закольцовывать надо — чтобы после последнего кадра анимации невозбранно мог идти первый кадр её.

[@Dlussky]

В статье эта фраза используется в контексте изменения скорости анимации. И от перезапуска анимации в момент смены частоты кадров никак не поможет закольцовывание.

[@Mithgol]

Ах вот оно что.

[@tigerforce]

У того же Impending заметны прыжки. Неужели они не догадались закольцевать?

[@tenbits]

Я также часто использую keyframes для спрайтовой анимации. Однажды мне нужна была «скриптовая» динамика, и вот скрипт для динамичного создания keyframes-правил и старта анимации: github. Там правда используется timing-function: step-start для «прыжков» по кадрам.
PS: работа с cssRules относительно дорогая процедура, поэтому нужно создавать подобные правила по-минимуму и кешировать их.

[@tenbits]

Ах, и забыл уточнить про закольцованость — проблема в первом и последнем фрайме — между ними нету интервала, поэтому происходит как бы «ускорение» в этом месте. Используя step-start надо оставлять «0%» пустым и стартовать с 100/ frameCount.

[@Ember]

Если сделать зум, то картинка «едет».

[@Mithgol]

Возможно, это зависит от браузера.

(Я пробовал «делать зум» в Firefox 18; картинка либо не «едет», либо термин «едет» для меня означает некоторое другое понятие.)

[@mayorovp]

Google Chrome 23.0.1271.95 m

При зуме размер картинки увеличивается, а шаг анимации остается прежним. Как результат — при малом увеличении видно, как картинка «проезжает» через рамку, при больших зумах — в рамке непонятно что.

Любопытно, что если нажать «обновить», то анимация «приспособится» к текущей величине зума и уже перестанет работать на стандартном масштабе.

[@Mithgol]

Можно предполагать, что Вы только что обнаружили баг в Хроме и поэтому Вам следует сообщить о нём производителю.

[@mayorovp]

Практика показывает, что багрепорты никогда не попадают разработчикам через техподдержку. Не знаю, как в гугле, а в российских компаниях на багрепорты отвечают предложением почистить кэш и перезагрузить компьютер. Ах да, еще требуют скриншоты, причем никогда не читают историю переписки (то есть если прислать скриншот, то запросят описание выполненных действий, а потом снова скриншот). Так что писать багрепорты без багтрекера меня отучили полностью.

А по поводу багов — я не думаю, что найденные мною вещи — баги. В ситуации с зумом не исключена ошибка скрипта (код в примере несколько неудобен для анализа). В ситуации же ниже — это просто особенность, поскольку поведение анимации при смене ее параметров наверняка не описывается стандартом.

[@Mithgol]

Так ведь есть багтрекер.

[@mayorovp]

Спасибо, но я по прежнему не уверен, баги ли это.

[@Mithgol]

По-моему, описанный Вами выше эффект с изменением размера картинки при сохранении прежнего шага анимации — это баг именно вебкита.

Если же у Вас остаются сомнения о том, насколько этот эффект вызван вебкитом, а насколько конкретным скриптом, то тогда можете ведь самостоятельно изготовить тестовую страницу вообще без скриптов (только HTML, в котором картинка с кадрами анимации и CSS с описанием анимации), и проверить её поведение, и тем невозбранно узнать желаемое.

Именно тогда Вам станет ясно, что следует делать.

[@mayorovp]

Google Chrome 23.0.1271.95 m

Выглядит так, как будто в момент смены частоты кадров браузер не возвращается к первому кадру, а перевычисляет текущий кадр. Проще всего наблюдать этот эффект, установив длительность анимации в районе 100 и плавно меняя ее. Видно, как при увеличении длительности номер текущего кадра уменьшается.

Очень похоже, что номер текущего кадра в недрах браузера вычисляется как floor((current_time() — start_time) * steps / duration) % steps, причем при изменении duration переменная start_time не меняется.

[@tagir_valeev]

Вот небольшое демо.

Мне сперва показали нормальную анимацию, а потом её спрятали и сказали, что мой браузер не поддерживается. У меня FF 17.0.1.

[@Mithgol]

У меня Firefox 18 (то есть бета-версия), анимация не прячется.

[@sayber]

Нечто похожие есть тут:
eu.battle.net/wow/ru/item/46140
В правом углу имеется возможность двигать предмет. Псевдо 3Д

Ну и сам клипарт media.blizzard.com/wow/renders/items/item46140.jpg