Repaint для больших картинок

[spmbt]

Интересно сходятся мысли со вчерашней статьёй, в которой тоже использовали Canvas для отрисовки огромного полотна с картинками: "Как создать визуальную библиотеку изображений с HTML5 Canvas"

[tapalapa]

Тестировал анимацию (цветные квадратики бегают по браузеру, отталкиваясь от его стенок). Вариант в DIV'ами, когда координаты задаются с помощью MARGIN'ов в десятки — сотни раз медленнее, чем вариант с рисованием квадратиков на CANVAS. Причём, чем больше квадратиков, тем разница заметнее.

[miolini]

Вы случайно не облачка рисовали для нового сайта Windows Azure?

[tapalapa]

Отнюдь

[chikuyonok]

Я уперся в эту проблему, когда мне надо было анимировать листалку из картинок большого разрешения весом 100-200kB.

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

Однако, я проверил эти примерные выкладки практикой: замена тега img на canvas принесло ускорение на порядок в Chrome и лучшую производительность в Opera (которая вообще выпала из рамок исследования скорости repaint). Firefox стал при этом более стабильным. Я объяснил все это переносом вычислений с процессора на видеокарту.

Вывод не совсем правильный: одно дело, когда у вас отмасштабированные картинки, которые заново масштабируются на каждом repaint-цикле (ещё нужно смотреть, какая именно область перерисовывается, потому что вполне вероятно, что браузер может перерисовывать очень большой контейнер, хотя поменялся маленький блок), другое дело, когда на canvas вы создали новое изображение, которое больше нет необходимости перерисовывать заново. Видеокарта тут не при чём.

[spmbt]

В предыдущей статье про Canvas автор оригинала тоже однозначно пришёл к выводу, что дело в аппаратном ускорении, поддерживаемом Canvas (строчки «Здесь мы можем увидеть внутреннюю силу HTML5 браузеров, ...»).

[chikuyonok]

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

Основной трюк нашего приложения в рисовании только карт, которые хорошо видно на экране.

Автор текущей статьи сделал вывод, что:

операции с картинками надо реализовывать средствами [canvas], которая нагружает видеокарту, не надо использовать обычные теги [img], которые служат простой презентации графики.

… при том что, например, обычная смена opacity у немасштабированной картинки будет работать практически с такой же скоростью, как и через canvas. То есть проблема тут не в том, что тэг <img> используется не по назначению, а в том, что на каждый repaint картинка дополнительно масштабируется. К тому же, аппаратное ускорение можно включить не только через canvas, но и через CSS Transforms/Transitions.

[ivnC]

Вопрос: а разве canvas не участвует в перерисовке всей страницы (когда она случается)? Или что имеете в виду под «repaint-циклом»?

Поясню свой вывод. Я менял обновлял канву n раз в секунду, и это было эффективнее, чем обновлять атрибут у тега img. Т.е. n раз в секунду из кеша бралась картинка и ложилась на канву, она, очевидно, каждый раз перерисовывалась.

[chikuyonok]

canvas – не участвует, потому что содержимое этого элемента не изменяется через стандартные reflow и CSS. В остальном, надо смотреть на код теста, чтобы понять, в чём проблема.

[Demetros]

Конкретно в случае слайдера может помочь анимация через scrollLeft/scrollTop.

[macik_spb]

Немножко в сторону от темы, но тем не менее
Вот здесь
chikuyonok.ru/2010/11/optimization-story/
статья Сергея Чикуенка о том, как они боролись с тормозами перерисовки, и почему они вообще были.