azproduction Feb 23 2011 at 15:32

Продвинутые анимации с requestAnimationFrame

3 min

68K

JavaScript*

Translation

+23

Comments 36

danilissimus Feb 23 2011 at 16:54

Ну-ну, а потом удивляетесь, почему «простая» анимация жрет 30-50% ресурсов CPU, а браузеры занимают по 300-400 мегабайт в памяти.
Уже 100 лет назад придумали GIF (причем по реальной необходимости) и APNG (тут можно о необходимости поспорить) — нет, мало! Придумаем, чего-бы еще такого засунуть в наш новый стандарт, чтобы все поняли, что мы не присиживаем штаны в своем консорциуме, а напичкиваем его новыми веб-два-нольными функциями, чтобы хомячью было удобнее фейсбуки и вконтакты просматривать. Как дети, ей богу.

yroman Feb 23 2011 at 16:58

А вы, наверное, в интернете через lynx сидите?

andre_colonel Feb 23 2011 at 18:29

К сожалению, то же Demo by Louis-Rémi Babé, с монохромными капельками забирает одно ядро процессора. Конечно умом понимаешь, что веб, что новые технологии, что все хорошо, и что так надо. А сердце помнит демки, которые на намного меньших ресурсах показывали всякое, и огорчается.

RussianSpy Feb 24 2011 at 00:18

Толсто. Ну, аватару зато соответствуете

Yanovsky Jul 6 2013 at 13:41

gif был придуман, чтобы сиськи анимировать

UFO landed and left these words here

azproduction Feb 23 2011 at 19:55

Canvas 2D всегда сглаживает и будет сглаживать(алиазные линии сейчас больше не нужны чем нужны). Стоит обратить внимание на алгоритм Брезенхэма либо нарисовать ступенчатые линии WebGL'ем

Smartfon Feb 23 2011 at 19:41

Плюс ко всему если выполняется анимация в табе, который невидим, браузеры не будут продолжать перерисовку

Что-то подобного не наблюдается в Хроме (последняя бета).

azproduction Feb 23 2011 at 20:01

Все работает. Хром 10.0.648.82 beta. В примере Demo by Louis-Rémi Babé нужно нажать Interval Bookmarklet затем включить [v] requestAnimationFrame. При смене таба нагрузка ЦП снижается с 28% до 7%

kirilloid Feb 23 2011 at 20:15

Вообще говоря, safari mobile давно уже таймеры не обрабатывает неактивной вкладке. Про другие ничего не знаю, но у меня есть подозрения, что реализовать это совсем не сложно и все это итак уже умеют.
А для десктопа это не так критично.

iStyx Feb 23 2011 at 21:54

function(/* function */ callback, /* DOMElement */ element){
                window.setTimeout(callback, 1000 / 60);
              };

Это ничего, что тут element теряется? Я бы сделал так:

function(/* function */ callback, /* DOMElement */ element){
                window.setTimeout(function() { callback.call(callback,element); }, 1000 / 60);
              };

azproduction Feb 23 2011 at 22:23

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

iStyx Feb 23 2011 at 22:48

А, ну да, ускользнуло как-то

TheShock Feb 24 2011 at 00:38

Ну что сказать, правильно всё.

TiGR Feb 24 2011 at 07:59

Не всё. fallback должна возвращать id таймера. Ну то есть, там должен быть return, согласно спецификации. Тогда можно будет организовать и останов анимации. Я написал об этом в комментах к оригинальной заметке, но Пол текст не исправил.

kashey Feb 25 2011 at 14:43

Как-то совсем совсем никакого эффекта кроме нормирования FPS не наблюдается.
Где обещанные оптимизация reflow — не знаю :(

TheShock May 6 2011 at 20:22

function(/* function */ callback, /* DOMElement */ element){
  window.setTimeout(callback, 1000 / 60);
};

Кажется, тут ошибка и необходимо так:

function(/* function */ callback, /* DOMElement */ element){
  window.setInterval(callback, 1000 / 60);
};

requestAnimationFrame вызывается приблизительно раз в 17 мс.
а если у меня вычисления длятся больше — он будет захлёбываться, или пропускать кадры?

TheShock May 6 2011 at 20:27

Понял, глупость сморозил.

trikadin Mar 31 2013 at 06:11

Эм, а можете пояснить? А то я тоже об этом задумался, но не понял, почему это глупость.

azproduction Mar 31 2013 at 06:48

17ms = 60 fps

trikadin Mar 31 2013 at 06:50

А, ну да, растянуть вычисления на 17ms — надо постараться.

TheShock Apr 1 2013 at 18:39

Я сказал глупость про setInterval вместо setTimeout. RAF работает как setTimeout

trikadin Apr 1 2013 at 22:40

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

azproduction Apr 2 2013 at 14:04

Она как setTimeout только с синхронизацией с «внутренним таймером перерисовки страницы» и не дает завышать rps

trikadin Apr 2 2013 at 15:46

Да нет, мне понятно, как работает requestAnimationFrame, вопрос про другое: если вычисления длятся дольше, чем 17ms, то он просто пропустит кадр, или будет ждать, пока они завершатся?

azproduction Apr 2 2013 at 16:07

Как и setTimeout будет ждать, но тут скорее особенность Event Loop.

trikadin Apr 2 2013 at 18:09

Ага, понятно, спасибо)

limon_spb Dec 20 2011 at 08:18

Простите, что поднимаю не очень новый пост, зашел через поиск.
Я новичек в js+canvas, наткнулся на проблему, на которую по моим ощущениям, как-то «забивают»:

даже самая простая анимация на канвасе в js, сделанная через setInterval с каким бы то ни было интервалом периодически устраивает небольшой еле-еле заметный подлаг (у меня раз в секунду в среднем).
Проверено не только на моем компьютере, но и еще на пяти. У кого-то раз в 5 сек, у кого-то раз в секунду.

Зашел на пример из этого топика
jsfiddle.net/paul/XQpzU/
и тоже самое — наблюдаю небольшие скачки раз в секунду, если внимательно смотреть.
Если анимация посложнее, то подлаги есть, просто их труднее разглядеть, если много чего «мельтешит».

При этом компьютер довольно мощный 4 ядра и все такое.

Похожий эффект наблюдается при анимации во flash.

Получается в браузерх пока что никак не реализовать более-менее гарантированное плавное движение?

TheShock Dec 20 2011 at 08:40

Это сборщик мусора запускается.

limon_spb Dec 20 2011 at 22:19

хм… И получается, что не реализовать плавное перемещение хотябы просто квадратика, а-ля директ Х, ОпенГЛ и т.п. из-за этого «сборщика мусора»?

TheShock Dec 20 2011 at 23:47

Сразу скажу, что я не особо эксперт в этих деталях, потому расскажу, как я понимаю ситуацию.
Я проверял эту ситуацию через хромопрофайлер — как раз во время запуска ГК слегка подлагивает изображение.
Да. Сборщик блокирует поток из-за которого один-другой кадр рендерится, скажем, в два раза дольше. И лучше было бы стабильных 30 фпс, чем 60 фпс, а один раз кадр одрендерённый в два раза медленнее.
В Си такой проблемы нету из-за ручной сборки мусора (вроде, в Джава тоже есть эти протормаживания?) и из-за того, что рендер лежит на видеокарте.
Может, поможет рендер через кадр, тогда лаги будут менее заметны
Хотя я всё же думаю, что это не так важно =)

limon_spb Dec 21 2011 at 07:32

Спасибо за пояснение!

azproduction Dec 21 2011 at 01:19

В Java тоже GC. GC есть разных типов: рефкаунт, который не блокирует поток, и блокирующий. Повсеместно используется блокирующий тк он может работать с циклическими ссылками.
Весь код основного потока JavaScript работает с одной кучей, каждый раз когда браузер понимает, что нужно почистить мусор он блокирует поток — чистит и дефрагементирует память. Время простоя зависит от количества созданных и убитых объектов и контекстов в один момент времени.
Пользователь видит GC как зависание окна. Я вот, например, часто вижу как висит WebStorm (Java)…
Управлять GC в JavaScript, в отличии от того же Питона, нельзя (отанавливать и запускать руками). Можно только в Опере принудительно вызывать GC.
Уменьшить время GC можно разбив кучу(Heap) на несколько мелких куч — те использовать Воркеры.

limon_spb Dec 21 2011 at 07:36

Спасибо!
А где про это в все javascript можно почитать подробнее?

azproduction Dec 21 2011 at 12:19

На хабре, у меня в хабраблоге habrahabr.ru/users/azproduction/blog/ или dmitrysoshnikov.com/

limon_spb Dec 22 2011 at 09:50

Благодарю за линки!