Как можно оптимизировать в JS покадровую анимацию на Canvas?

Question

[Сергей]

Есть JS скрипт, где есть массив из Image объектов уже загруженных (фреймы анимации PNG формата), и есть canvas.
Так же есть функция которая очищает canvas (clearRect) и потом при помощи drawImage рисует следующий кадр из массива.
Проблема в том, что если взять два (или более) канваса с покадровой анимацией и проигрывать их одновременно, начинаются сильные просадки FPS.
Есть ли какие нибудь пути оптимизации такой анимации, чтобы они тратили меньше ресурсов и соответственно кадры рисовались быстрее.

Comments

[Сергей Соколов]

как вы рисуете следующий кадр - по setTimeout или requestAnimationFrame?

[Сергей]

Сергей Соколов, по setTimeout так как необходимо конкретное число кадров в секунду без потерь кадров.
Поэтому ищу методы оптимизации именно с операциями самого canvas и может быть смены способа нанесения и хранения кадров.
Сейчас кадры подгружаются заранее в виде объекта Image в общий массив по порядку. И потом при необходимости, начинают рисоваться из этого массива при помощи drawImage.

[RAX7]

Сергей, setTimeout не лучший способ анимации, используй requestAnimationFrame. Лучше использовать один requestAnimationFrame для всех отрисовок.

[Сергей]

RAX7, при нагрузке в requestAnimationFrame теряются кадры так как есть жесткое ограничение в которое нужно успеть уложиться. Это хорошо для простого показа анимации, где не критична потеря кадров и незначительные дерганья. В моем случае важно чтоб было определенное кол-во кадров в секунду и каждый кадр был показан.

[RAX7]

Сергей, так с setTimeout они будут теряться, setTimeout не гарантирует что коллбэк будет вызван через заданное время, он гарантирует что коллбэк будет вызван не ранее чем через заданное время. Если сама анимация слишком тяжелая, то как не крути - кадры будет теряться. Если есть возможность воспроизведи проблему в песочнице, может тогда понятно будет из-за чего просадки в кадрах.

[Сергей]

RAX7, главное что он будет вызван, если даже с задержкой и кадр будет отрисован. В requestAnimationFrame у меня терялись кадры и в итоге из 100 кадров могло быть отрисовано только 97 например.
Да скидывать часть кода не понятно будет, а весь проект нет смысла, он не маленький и в нем разбираться вряд ли кто то будет))
Есть два или более канваса в которые просто из массива с объектами Image в js при помощи drawImage наносится изображение по таймеру, вот и вся логика. Просто думал может есть более быстрые способы нанесения фреймов в канвас, или их хранения не в виде Image а может как то по другому.

[RAX7]

Сергей, requestAnimationFrame тоже будет вызван в любом случае. Видимо ты просто не правильно считаешь какой кадр должен быть отрисован в каждый конкретный момент вызова requestAnimationFrame / setTimeout.
Более быстрый способ - это webgl, но судя по поставленной задаче он вряд ли поможет, потому что и обычный канвас должен справляться с этим без проблем.

[Сергей]

RAX7, хм надо будет снова изучить, но помниться что отказ от requestAnimationFrame был именно по этой причине, может были еще какие то вспомнить сложно. Но изначально он и был.
Есть ли еще методы оптимизации именно отрисовки канвас кроме requestAnimationFrame?

[RAX7]

Сергей, https://developers.google.com/web/updates/2018/08/...

[Сергей]

RAX7, да в курсе, но до сих пор даже в WebView Chromium 80 на мобилках он не поддерживается.
А может есть способы менее затратнее отрисовать PNG в канвас, например не через drawImage или может хранить кадры не как объект Image в массиве и брать оттуда, а как то по другому?!

[RAX7]

Сергей, чудес не бывает. Ищи узкие места в коде, запусти профайлер и смотри что съедает больше всего времени, по результатам уже будешь думать что делать с этою бедой.
Или всё же смотреть в сторону webgl. Вот тест отрисовки спрайтов на pixijs , под капотом там как раз webgl

[Сергей]

RAX7, да уж понимаю, думал возможно рисовать как то иначе. Буду думать)

ну там кешированые штук 5 спрайтов я так понимаю и они очень маленькие. У меня идёт смена кадров размером не ниже 2к и они не повторяются)
webgl вроде наоборот больше ресурсов есть разве нет? по крайней мере так вроде пишут. Там же идёт 2д и 3д графика, а у меня чистое 2д рисование на канвасе.

Answer 1

[Сергей Соколов]

я бы использовал не setTimeout(), a именно requestAnimationFrame()
Внутри известно прошедшее время и можно понять, какой кадр сейчас должен отображаться.

Надо запоминать, какой кадр сейчас отображён: надо ли его перерисовывать, или requestAnimationFrame() успел сработать дважды во время одного кадра и перерисовки не требуется.

Так анимации будут жестко привязаны ко времени. Даже если из-за низкой производительности какой-то кадр окажется пропущен, общая скорость анимаций привязана ко времени, и рассинхрона не возникнет.
Вместо «торможения», замедления — могут проглатываться кадры. Но скорость движения персонажа в анимации останется прежней, хоть и менее плавной.

Comments

[Сергей]

изначально в алгоритме был именно requestAnimationFrame но кадры как раз некоторые пропадали, поэтому стал использоваться setTimeout. Поэтому тут приходится искать другие пути оптимизации, так как важно чтобы все кадры были отрисованы, а заторможенность и плавность анимации это вторично.
Отсюда и вопрос такой именно про оптимизацию прорисовки кадров :)

[Сергей Соколов]

Сергей, тут уже погружение в тёмные области видео-кодеков и компресии.
Перерисовывать не целиком полотно, а только изменившиеся области.
Размеры картинок и canvas 1:1 или размер меняется налету?
Вообще интересно понять, где узкое место может быть..

[Сергей Соколов]

а видео не будет быстрее проигрываться?

[Сергей]

Сергей Соколов, размер 1:1
была идея тоже попробовать видео с прозрачностью отрисовывать. WEBP вроде может содержать альфа канал, но надо тестировать будет ли вообще быстрее рисоваться кадр, а то может и даже хуже станет.
У меня была мысля искать альтернативу drawImage если вообще возможно что то такое сделать, и может хранить фреймы не в виде Image в массиве, а как то иначе. Но пока ничего не нашел.
Если не найду действительно попробую использовать видео с прозрачностью

[Сергей]

Кстати по девтулс перфоманс показывает самый долгий процесс это Image Decode
Тут в тесте сразу на двух канвасах рисуются кадры и уже очень заметно падает фпс.

[Сергей Соколов]

Сергей, поверхностный гуглинг навёл, что "Image Decode" происходит и при анимации объекта поверх картинки.

Поясните подробнее, что там у вас – чтобы по комментариям не собирать крупицы. Как я уже понял, размеры каждой из канв — под 2000x2000px? В них отрисовываются кадры с прозрачностью. Ещё какой-то контент - где - под/над канвой? В чём вообще смысл затеи? Почему важнее прорисовка каждого из кадров, чем сохранение реалистичного тайминга?