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

[@danilissimus]

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

[@yroman]

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

[@andre_colonel]

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

[@RussianSpy]

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

[@Yanovsky]

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

[@azproduction]

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

[@Smartfon]

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

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

[@azproduction]

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

[@kirilloid]

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

[@iStyx]

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]

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

[@iStyx]

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

[@TheShock]

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

[@TiGR]

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

[@kashey]

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

[@TheShock]

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

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

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

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

[@TheShock]

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

[@trikadin]

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

[@azproduction]

17ms = 60 fps

[@trikadin]

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

[@TheShock]

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

[@trikadin]

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

[@azproduction]

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

[@trikadin]

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

[@azproduction]

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

[@trikadin]

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

[@limon_spb]

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

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

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

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

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

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

[@TheShock]

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

[@limon_spb]

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

[@TheShock]

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

[@limon_spb]

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

[@azproduction]

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

[@limon_spb]

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

[@azproduction]

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

[@limon_spb]

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