CSS GPU Animation: все правильно

1. Об авторе Сергей Чикуенок - российский веб-разработчик и писатель, который увлекается оптимизацией:...
2. Один большой отказ от ответственности
3. Как работает композитинг
4. Неявное наложение
5. Потребление памяти
6. Плюсы и минусы
7. Pros
8. Настройка браузера
9. Сафари
10. Хром
11. Советы по оптимизации
12. Избегайте неявного составления
13. Уменьшить размер составного слоя
14. Используйте CSS переходы и анимации, когда это возможно
15. Пример оптимизации в реальном времени
16. Уроки выучены

Об авторе

Наша взаимовыгодная связь https://banwar.org/

Сергей Чикуенок - российский веб-разработчик и писатель, который увлекается оптимизацией: от изображений и эффектов JavaScript до рабочего процесса и… Подробнее о Сергее…

Большинство людей теперь знают, что современные веб-браузеры используют графический процессор для визуализации частей веб-страниц, особенно с анимацией. Например, CSS-анимация с использованием свойства transform выглядит намного плавнее, чем анимация с использованием свойств left и top. Но если вы спросите: «Как получить плавную анимацию из графического процессора?», В большинстве случаев вы услышите что-то вроде: «Используйте transform: translateZ (0) или will-change: transform». Эти свойства стали чем-то вроде как мы использовали zoom: 1 для Internet Explorer 6 (если вы меня улавливаете) с точки зрения подготовки анимации для графического процессора или компоновки , как любят называть производители браузеров. Но иногда анимация, которая хороша и плавна в простой демонстрации, очень медленно работает на реальном веб-сайте, вводит визуальные артефакты или даже приводит к сбою браузера. Почему это происходит? Как мы это исправим? Давайте попробуем понять.

Большинство людей теперь знают, что современные веб-браузеры используют графический процессор для визуализации частей веб-страниц, особенно с анимацией. Например, CSS-анимация с использованием свойства transform выглядит намного плавнее, чем анимация с использованием свойств left и top. Но если вы спросите: «Как получить плавную анимацию из графического процессора?», В большинстве случаев вы услышите что-то вроде: «Используйте transform: translateZ (0) или will-change: transform».

Эти свойства стали чем-то вроде того, как мы использовали zoom: 1 для Internet Explorer 6 (если вы меня улавливаете) с точки зрения подготовки анимации для графического процессора или компоновки , как любят называть производители браузеров.

Дальнейшее чтение на SmashingMag:

Но иногда анимация, которая хороша и плавна в простой демонстрации, очень медленно работает на реальном веб-сайте, вводит визуальные артефакты или даже приводит к сбою браузера. Почему это происходит? Как мы это исправим? Давайте попробуем понять.

Один большой отказ от ответственности

Самое важное, что я хотел бы сказать вам, прежде чем мы углубимся в композитинг на GPU, это: это гигантский взлом . Вы не найдете ничего (по крайней мере пока) в W3C Спецификации о том, как работает композитинг, о том, как явно поместить элемент в слой композитинга или даже о самом композитинге. Это просто оптимизация, которую браузер применяет для выполнения определенных задач и которую каждый поставщик браузеров реализует по-своему.

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

Как работает композитинг

Чтобы подготовить страницу для анимации на GPU, мы должны понять, как все работает в браузере, а не просто следовать случайным советам из Интернета или из этой статьи.

Допустим, у нас есть страница с элементами A и B, каждый из которых имеет позицию: absolute и к ней применен другой z-индекс. Браузер раскрасит его из процессора, а затем отправит полученное изображение в графический процессор, который отобразит его на экране.

<style> #a, #b {position: absolute; } #a {слева: 30 пикселей; верх: 30 пикселей; z-индекс: 2; } #b {z-index: 1; } </ style> <div id = "# a"> A </ div> <div id = "# b"> B </ div>

Мы решили анимировать элемент A, переместив его с помощью свойства left и CSS-анимации:

<style> #a, #b {position: absolute; } #a {слева: 10 пикселей; верх: 10 пикселей; z-индекс: 2; анимация: ход 1с линейный; } #b {слева: 50 пикселей; верх: 50 пикселей; z-индекс: 1; } @keyframes move {от {слева: 30 пикселей; } до {слева: 100 пикселей; }} </ style> <div id = "# a"> A </ div> <div id = "# b"> B </ div>

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

Переформатывание и перерисовка всей страницы на каждом этапе анимации (даже постепенно) звучит очень медленно, особенно для большого и сложного макета. Было бы намного эффективнее просто нарисовать два отдельных изображения - одно для элемента А и одно для всей страницы без элемента А, а затем просто сместить эти изображения относительно друг друга. Другими словами, составление изображений кэшированных элементов будет быстрее. И это именно то место, где сияет графический процессор: он способен очень быстро составлять изображения с точностью до субпикселя , что добавляет сексуальной плавности анимации.

Для оптимизации компоновки браузер должен убедиться, что анимированное свойство CSS:

• не влияет на поток документов,
• не зависит от потока документов,
• не вызывает перекраски.

Можно подумать, что свойства top и left, наряду с абсолютными и фиксированными позициями, не зависят от среды элемента, но это не так. Например, левое свойство может получить процентное значение, которое зависит от размера .offsetParent; также em, vh и другие единицы зависят от их окружения. Скорее, transform и opacity - единственные свойства CSS, которые удовлетворяют указанным выше условиям.

Давайте оживим с помощью transform вместо left:

<style> #a, #b {position: absolute; } #a {слева: 10 пикселей; верх: 10 пикселей; z-индекс: 2; анимация: ход 1с линейный; } #b {слева: 50 пикселей; верх: 50 пикселей; z-индекс: 1; } @keyframes move {from {transform: translateX (0); } преобразовать: translateX (70px); }} </ style> <div id = "# a"> A </ div> <div id = "# b"> B </ div>

Здесь мы описали нашу анимацию декларативно : ее начальная позиция, конечная позиция, продолжительность и т. Д. Это заранее сообщает браузеру, какие свойства CSS будут обновлены. Поскольку браузер видит, что ни одно из свойств не вызовет перекомпоновку или перерисовку, он может применить оптимизацию компоновки: рисовать два изображения в виде слоев компоновки и отправлять их в графический процессор.

Каковы плюсы такой оптимизации?

• Мы получаем шелковистую плавную анимацию с субпиксельной точностью, которая выполняется на устройстве, специально оптимизированном для графических задач. И это работает очень быстро.
• Анимация больше не привязана к процессору. Даже если вы выполняете очень интенсивную задачу JavaScript, анимация все равно будет работать быстро.

Все кажется довольно ясным и легким, верно? С какими проблемами мы можем столкнуться? Давайте посмотрим, как эта оптимизация действительно работает.

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

Чтобы лучше понять, как это работает, подумайте об AJAX. Предположим, вы хотите зарегистрировать посетителя веб-сайта с данными, введенными в веб-форму. Вы не можете просто сказать удаленному серверу: «Эй, просто возьмите данные из этих полей ввода и этой переменной JavaScript и сохраните их в базе данных». Удаленный сервер не имеет доступа к памяти в браузере пользователя. Вместо этого вам придется собирать данные со страницы в полезную нагрузку с простым форматом данных, который можно легко проанализировать (например, JSON), и отправить их на удаленный сервер.

Нечто очень похожее происходит во время композитинга. Поскольку графический процессор подобен удаленному серверу, браузер должен сначала создать полезную нагрузку, а затем отправить ее на устройство. Конечно, GPU не за тысячи километров от процессора; это прямо там Однако в то время как 2 секунды, требуемые для запроса и ответа удаленного сервера, были бы приемлемы во многих случаях, дополнительные 3-5 миллисекунд для передачи данных с графического процессора привели бы к ненужной анимации.

Как выглядит полезная нагрузка графического процессора? В большинстве случаев он состоит из изображений слоев вместе с дополнительными инструкциями, такими как размер слоя, смещение, параметры анимации и т. Д. Вот примерно то, как выглядит создание полезной нагрузки и передача данных с помощью графического процессора:

• Нарисуйте каждый композитный слой на отдельное изображение.
• Подготовьте данные слоя (размер, смещение, непрозрачность и т. Д.).
• Подготовьте шейдеры для анимации (если применимо).
• Отправьте данные в графический процессор.

Как видите, каждый раз, когда вы добавляете магическое преобразование: translateZ (0) или свойство will-change: transform к элементу, вы запускаете один и тот же процесс. Хотя перекраска очень затратна по производительности, здесь она еще медленнее. В большинстве случаев браузер не может постепенно перекрашивать. Это должно нарисовать область, которая была ранее покрыта недавно созданным составным слоем:

Неявное наложение

Давайте вернемся к нашему примеру с элементами A и B. Ранее мы анимировали элемент A, который расположен поверх всех других элементов на странице. В результате получилось два слоя компоновки: один с элементом A, другой с элементом B и фоном страницы.

Теперь давайте вместо этого анимируем элемент B:

Мы столкнулись с логической проблемой. Элемент B должен находиться на отдельном композитном слое, а окончательное изображение страницы для экрана должно быть скомпоновано на GPU. Но элемент A должен появиться поверх элемента B, и мы не указали ничего о A, которое бы продвигало его на его собственный уровень.

Помните большой отказ от ответственности : специальный режим компоновки GPU не является частью спецификации CSS; это просто оптимизация, которую браузер применяет внутри. Мы должны иметь A появляться сверху B именно в том порядке, как определено z-index. А что будет делать браузер?

Ты угадаешь это! Он принудительно создаст новый композитный слой для элемента A - и, конечно, добавит еще один тяжелый перекрас:

Это называется неявным составлением : один или несколько нескомпонованных элементов, которые должны отображаться над составным элементом в порядке наложения, переводятся в составные слои, то есть раскрашиваются в отдельные изображения, которые затем отправляются в графический процессор.

Мы сталкиваемся с неявным сочинением гораздо чаще, чем вы думаете. Браузер будет продвигать элемент в слой композитинга по многим причинам, лишь некоторые из которых:

• 3D-преобразования: translate3d, translateZ и т. Д .;
• элементы <video>, <canvas> и <iframe>;
• анимация трансформации и непрозрачности через Element.animate ();
• анимация трансформации и непрозрачности через СSS переходы и анимации;
• положение: фиксированное;
• изменится ;
• фильтр ;

Больше причин описано в CompositingReasons.h Файл проекта Chromium.

Похоже, основная проблема анимации на GPU - неожиданные тяжелые перерисовки. Но это не так. Большая проблема ...

Потребление памяти

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

Сколько памяти занимает один составной слой? Давайте возьмем простой пример. Попробуйте угадать, сколько памяти требуется для хранения прямоугольника размером 320 × 240 пикселей, заполненного сплошным цветом # FF0000.

Типичный веб-разработчик подумает: «Хм, это сплошное изображение. Я сохраню это как PNG и проверю его размер. Он должен быть меньше 1 КБ ». И они были бы абсолютно правы: размер этого изображения в формате PNG составляет 104 байта.

Проблема в том, что PNG, наряду с JPEG, GIF и т. Д., Используются для хранения и передачи данных изображения. Чтобы нарисовать такое изображение на экране, компьютер должен распаковать его из формата изображения и затем представить его в виде массива пикселей . Таким образом, наше примерное изображение заняло бы 320 × 240 × 3 = 230 400 байт памяти компьютера. То есть мы умножаем ширину изображения на его высоту, чтобы получить количество пикселей в изображении. Затем мы умножаем его на 3, потому что каждый пиксель описывается тремя байтами (RGB). Если изображение содержит прозрачные области, мы умножим его на 4, потому что для описания прозрачности требуется дополнительный байт: (RGBa): 320 × 240 × 4 = 307 200 байтов.

Браузер всегда рисует композитные слои как изображения RGBa. Кажется, что нет эффективного способа определить, содержит ли элемент прозрачные области.

Давайте рассмотрим более вероятный пример: карусель с 10 фотографиями, каждая размером 800 × 600 пикселей. Мы решили плавно переходить между изображениями при взаимодействии с пользователем, например при перетаскивании, поэтому добавляем will-change: transform для каждого изображения. Это будет продвигать изображения в составные слои заблаговременно, так что переход начинается сразу же после взаимодействия с пользователем. Теперь вычислите, сколько дополнительной памяти требуется для отображения такой карусели: 800 × 600 × 4 × 10 ≈ 19 МБ .

Для отображения одного элемента управления требуется 19 МБ дополнительной памяти! И если вы современный веб-разработчик, который создает веб-сайт в виде одностраничного приложения с множеством анимированных элементов управления, эффектов параллакса, изображений с высоким разрешением и других визуальных улучшений, то дополнительные 100–200 МБ на страницу - это только начало. Добавьте неявную композицию в микс (признайте это - вы даже не думали об этом раньше), и вы получите страницу, заполняющую всю доступную память на устройстве.

Более того, во многих случаях эта память будет потрачена впустую, показывая тот же результат:

Это может не быть проблемой для настольных клиентов, но это действительно вредит мобильным пользователям. Во-первых, большинство современных устройств имеют экраны высокой плотности: умножьте вес составных изображений на 4–9. Во-вторых, мобильные устройства не имеют столько памяти, сколько настольные компьютеры. Например, не очень старый, но все же iPhone 6 поставляется с 1 ГБ общей памяти (т. Е. Память, используемая как для оперативной памяти, так и для VRAM). Учитывая, что по крайней мере одна треть этой памяти используется операционной системой и фоновыми процессами, другая треть - браузером и текущей страницей (лучший вариант для высоко оптимизированной страницы без тонны фреймворков), мы остались максимум от 200 до 300 МБ для эффектов графического процессора. И iPhone 6 - довольно дорогое устройство высокого класса; более доступные телефоны содержат гораздо меньше памяти на борту.

Вы можете спросить: «Можно ли сохранить изображения PNG в графическом процессоре, чтобы уменьшить объем памяти?» Технически, да, это возможно. Единственная проблема в том, что GPU рисует экран попиксельно Это означает, что он должен снова и снова декодировать целое PNG-изображение для каждого пикселя. Я сомневаюсь, что анимация в этом случае будет быстрее, чем 1 кадр в секунду.

Ничего не стоит, что GPU-специфичный форматы сжатия изображений существуют, но они даже не близки к PNG или JPEG с точки зрения степени сжатия, и их использование ограничено аппаратной поддержкой.

Плюсы и минусы

Теперь, когда мы изучили некоторые основы анимации на GPU, давайте подведем итоги ее плюсов и минусов.

Pros

• Анимация быстрая и плавная, со скоростью 60 кадров в секунду.
• Правильно созданная анимация работает в отдельном потоке и не блокируется тяжелыми вычислениями JavaScript.
• 3D-трансформации «дешевы».

Cons

• Требуется дополнительная перекраска для продвижения элемента в составной слой. Иногда это происходит очень медленно (т. Е. Когда мы получаем перекрашивание в полном слое, а не в пошаговом).
• Окрашенные слои должны быть переданы в графический процессор. В зависимости от количества и размера этих слоев передача может быть очень медленной. Это может привести к мерцанию элемента на устройствах низкого и среднего уровня.
• Каждый составной слой потребляет дополнительную память. Память является ценным ресурсом на мобильных устройствах. Чрезмерное использование памяти может привести к сбою браузера .
• Если вы не учитываете неявное наложение, шансы на медленное перекрашивание, дополнительное использование памяти и сбои браузера очень высоки.
• Мы получаем визуальные артефакты, например при рендеринге текста в Safari, и содержимое страницы в некоторых случаях исчезает или искажается.

Как видите, несмотря на некоторые очень полезные и уникальные преимущества, анимация на GPU имеет некоторые очень неприятные проблемы. Наиболее важными из них являются перекраска и чрезмерное использование памяти; Таким образом, все методы оптимизации, описанные ниже, решат эти проблемы.

Настройка браузера

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

Сафари

Веб-инспектор Safari имеет потрясающую боковую панель «Слои», которая отображает все составные слои и их потребление памяти, а также причину композитинга. Чтобы увидеть эту боковую панель:

1. В Safari откройте веб-инспектор с помощью ⌘ + ⌥ + I. Если это не сработает, откройте «Предпочтения» → «Дополнительно», включите параметр «Показать меню разработки в строке меню» и повторите попытку.
2. Когда веб-инспектор откроется, выберите вкладку «Элементы» и выберите «Слои» на правой боковой панели.
3. Теперь, когда вы щелкнете по узлу DOM на главной панели «Элементы», вы увидите информационный слой для выбранного элемента (если он использует композитинг) и всех дочерних составных слоев.
4. Нажмите на слой-потомок, чтобы увидеть причину, по которой он был составлен. Браузер скажет вам, почему он решил переместить этот элемент на свой собственный слой композитинга.

( Посмотреть большую версию )

Хром

DevTools в Chrome имеет похожую панель, но сначала нужно включить флаг:

1. В Chrome перейдите в chrome: // flags / # enable-devtools-эксперименты и включите флаг «Эксперименты с инструментами разработчика».
2. Откройте DevTools с помощью ⌘ + ⌥ + I (на Mac) или Ctrl + Shift + I (на ПК), а затем щелкните следующий значок в верхнем правом углу и выберите пункт меню «Настройки».
3. Перейдите на панель «Эксперименты» и включите панель «Слои».
4. Откройте DevTools. Теперь вы должны увидеть панель «Слои».

( Посмотреть большую версию )

Эта панель отображает все активные слои композиции текущей страницы в виде дерева. Когда вы выберете слой, вы увидите такую ​​информацию, как его размер, потребление памяти, количество перерисовок и причину компоновки.

Советы по оптимизации

Теперь, когда мы настроили нашу среду, мы можем приступить к оптимизации уровня композитинга. Мы уже определили две основные проблемы с компоновкой: дополнительные перерисовки, которые также вызывают передачу данных в графический процессор, и дополнительное потребление памяти. Итак, все советы по оптимизации ниже будут сосредоточены именно на этих проблемах.

Избегайте неявного составления

Это самый простой и очевидный совет, но очень важный. Напомню, что все некомпозиционные элементы DOM выше одного с явной причиной компоновки (например, position: fixed, video, CSS animation и т. Д.) Будут принудительно перенесены в свои собственные слои только для окончательной компоновки изображения на GPU. На мобильных устройствах это может привести к медленному запуску анимации.

Давайте рассмотрим простой пример:

Элемент A должен быть анимирован при взаимодействии с пользователем. Если вы посмотрите на эту страницу на панели «Слои», то увидите, что никаких дополнительных слоев нет. Но сразу после нажатия кнопки «Воспроизвести» вы увидите еще несколько слоев, которые будут удалены сразу после завершения анимации. Если вы посмотрите на этот процесс на панели «Временная шкала», то увидите, что начало и конец анимации сопровождаются перерисовкой больших областей:

( Посмотреть большую версию )

Вот что сделал браузер, шаг за шагом:

1. Сразу после загрузки страницы браузер не находит причин для компоновки, поэтому он выбирает оптимальную стратегию: раскрасить все содержимое страницы в один фоновый слой.
2. Нажав кнопку «Воспроизвести», мы явно добавляем композицию в элемент A - переход со свойством transform. Но браузер определяет, что элемент A находится ниже элемента B в порядке наложения, поэтому он также продвигает B на свой собственный уровень композитинга (неявное композитирование).
3. Переход на слой композитинга всегда вызывает перерисовку: браузер должен создать новую текстуру для элемента и удалить ее из предыдущего слоя.
4. Изображения нового слоя должны быть переданы в графический процессор для окончательной композиции изображения, которую пользователь увидит на экране. В зависимости от количества слоев, размера текстуры и сложности содержимого, перерисовка и передача данных могут занять значительное время. Вот почему мы иногда видим мерцание элемента, когда анимация начинается или заканчивается.
5. Сразу после завершения анимации мы удаляем причину компоновки из элемента A. Еще раз, браузер видит, что ему не нужно тратить ресурсы на компоновку, поэтому он прибегает к оптимальной стратегии: хранение всего содержимого страницы на одном слое, что означает, что он должен рисовать A и B обратно на фоне слой (еще один перекрас) и отправить обновленную текстуру в графический процессор. Как и в предыдущем шаге, это может вызвать мерцание.

Чтобы избавиться от неявных проблем с компоновкой и уменьшить визуальные артефакты, я рекомендую следующее:

• Старайтесь держать анимированные объекты как можно выше в z-index. В идеале эти элементы должны быть прямыми потомками элемента тела. Конечно, это не всегда возможно в разметке, когда анимированный элемент вложен глубоко в дерево DOM и зависит от нормального потока. В таких случаях вы можете клонировать элемент и поместить его в тело только для анимации.
• Вы можете дать браузеру подсказку, что вы собираетесь использовать композитинг с изменится CSS свойство С этим свойством, установленным для элемента, браузер (но не всегда!) Заранее продвигает его на слой композиции, чтобы анимация могла плавно запускаться и останавливаться. Но не злоупотребляйте этим свойством, иначе вы получите огромное увеличение потребления памяти!

Свойства transform и opacity гарантированно не влияют и не зависят от нормального потока или среды DOM (то есть они не вызывают перекомпоновку или перерисовку, поэтому их анимация может быть полностью выгружена в графический процессор). По сути, это означает, что вы можете эффективно анимировать только движения, масштабирование, вращение, прозрачность и аффинные преобразования. Иногда вы можете захотеть эмулировать другие типы анимации с этими свойствами.

Возьмите очень распространенный пример: переход цвета фона. Основной подход заключается в добавлении свойства перехода:

<div id = "bg-change"> </ div> <style> # bg-change {width: 100px; высота: 100 пикселей; фон: красный; переход: фон 0,4 с; } # bg-change: hover {background: blue; } </ style>

В этом случае анимация будет работать полностью на процессоре и вызывать перерисовку на каждом шаге анимации. Но мы можем заставить такую ​​анимацию работать на GPU: вместо анимации свойства background-color, мы добавили бы слой сверху и анимировали его непрозрачность:

<div id = "bg-change"> </ div> <style> # bg-change {width: 100px; высота: 100 пикселей; фон: красный; } # bg-change :: before {background: blue; непрозрачность: 0; переход: непрозрачность 0,4 с; } # bg-change: hover :: before {opacity: 1; } </ style>

Эта анимация будет намного быстрее и плавнее, но имейте в виду, что она может вызвать неявное наложение и потребовать дополнительной памяти. Тем не менее, в этом случае потребление памяти может быть значительно снижено.

Уменьшить размер составного слоя

Посмотрите на изображения ниже. Заметили разницу?

Эти два составных слоя визуально идентичны , но первый весит 40000 байт (39 КБ), а второй всего 400 байтов - в 100 раз меньше. Зачем? Посмотрите на код:

<div id = "a"> </ div> <div id = "b"> </ div> <style> #a, #b {will-change: transform; } #a {width: 100px; высота: 100 пикселей; } #b {width: 10px; высота: 10 пикселей; преобразование: масштаб (10); } </ style>

Разница заключается в том, что физический размер #a составляет 100 × 100 пикселей (100 × 100 × 4 = 40000 байт), тогда как #b составляет всего 10 × 10 пикселей (10 × 10 × 4 = 400 байт), но масштабируется до 100 × 100 пикселей с преобразованием: масштаб (10). Поскольку #b является составным слоем, благодаря свойству will-change преобразование теперь полностью выполняется в графическом процессоре во время окончательного рисования изображения.

Трюк довольно прост: уменьшите физический размер составного слоя с помощью свойств width и height, а затем увеличьте его текстуру с помощью transform: scale (…). Конечно, этот прием значительно снижает потребление памяти только для очень простых однотонных слоев. Но, например, если вы хотите анимировать большую фотографию, вы можете уменьшить ее на 5-10%, а затем увеличить ее; пользователи могут не увидеть никакой разницы, и вы сэкономите несколько мегабайт драгоценной памяти.

Используйте CSS переходы и анимации, когда это возможно

Мы уже знаем, что анимация преобразования и непрозрачности с помощью CSS-переходов или анимации автоматически создает слой композитинга и работает на графическом процессоре. Мы также могли бы анимировать с помощью JavaScript, но нам нужно было бы сначала добавить transform: translateZ (0) или will-change: transform, opacity, чтобы гарантировать, что элемент получит свой собственный слой композитинга.

Анимация JavaScript происходит, когда каждый шаг вычисляется вручную в обратном вызове requestAnimationFrame. Анимация через Element.animate () это вариация декларативной CSS-анимации.

С одной стороны, создать простую и многократно используемую анимацию с помощью CSS-перехода или анимации очень просто; с другой стороны, создание сложной анимации с причудливыми траекториями намного проще с JavaScript-анимацией, чем с CSS. Кроме того, JavaScript является единственным способом взаимодействия с пользовательским вводом.

Какой из них лучше? Можем ли мы просто использовать универсальную библиотеку JavaScript для анимации всего?

Анимация на основе CSS имеет очень важную особенность: она полностью работает на графическом процессоре . Поскольку вы объявляете, как анимация должна начинаться и заканчиваться, браузер может подготовить все необходимые инструкции до начала анимации и отправить их в графический процессор. В случае императивного JavaScript все, что браузер точно знает, это состояние текущего фрейма. Для плавной анимации нам нужно будет рассчитать новый кадр в основном потоке браузера и отправить его в графический процессор не менее 60 раз в секунду. Помимо того, что эти вычисления и отправка данных намного медленнее, чем CSS-анимация, они также зависят от загруженности основного потока:

На рисунке выше вы можете видеть, что происходит, когда основной поток блокируется интенсивными вычислениями JavaScript. На анимацию CSS это не влияет, потому что новый кадр вычисляется в отдельном потоке, тогда как анимация JavaScript должна дождаться завершения тяжелого вычисления, а затем вычислить новый кадр.

Поэтому старайтесь максимально использовать CSS-анимацию, особенно для индикаторов загрузки и прогресса. Это не только намного быстрее, но и не будет блокироваться тяжелыми вычислениями JavaScript.

Пример оптимизации в реальном времени

Эта статья является результатом моего исследования и экспериментов по разработке веб-страницы для Борцы Хаоса , Это отзывчивая промо-страница для мобильной игры с множеством анимаций. Когда я начинал ее разработку, я знал только то, как создавать анимацию на основе графического процессора, но я не знал, как она работает. В результате на самой первой веховой странице iPhone 5 - самый последний на тот момент телефон Apple - рухнул через несколько секунд сразу после загрузки страницы. Теперь эта страница отлично работает даже на менее мощных устройствах.

Давайте рассмотрим, на мой взгляд, наиболее интересную оптимизацию этого сайта.

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

Кажется, все работает как положено. Но вес изображения Солнца довольно тяжелый. Мобильные пользователи не будут счастливы.

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

Для этой оптимизации нам придется немного усложнить разметку: .sun будет контейнером для элементов с изображениями лучей. Каждый луч будет вращаться под определенным углом.

Визуальный результат будет таким же, но объем передаваемых по сети данных будет намного ниже. Тем не менее, размер составного слоя остается неизменным: 500 × 500 × 4 ≈ 977 КБ.

Для простоты размер солнечных лучей в нашем примере довольно мал, всего 500 × 500 пикселей. На реальном веб-сайте, обслуживающем устройства с различными размерами (мобильными, планшетными и настольными компьютерами) и плотностью пикселей, конечное изображение будет примерно 3000 × 3000 × 4 = 36 МБ! И это всего лишь один анимированный элемент на странице.

Посмотрите на разметку страницы еще раз на панели «Слои». Мы упростили вращение всего солнечного контейнера. Итак, этот контейнер был переведен в слой композитинга и раскрашен в одно большое текстурное изображение, которое затем было отправлено в графический процессор. Но из-за нашего упрощения текстура теперь содержит бесполезные данные : промежутки между лучами.

Более того, бесполезные данные намного больше по размеру, чем полезные данные! Это не лучший способ потратить наш очень ограниченный ресурс памяти.

Решение этой проблемы такое же, как и при нашей оптимизации передачи по сети: отправляйте только полезные данные (т.е. лучи) в графический процессор. Мы можем рассчитать, сколько памяти мы сэкономим:

• весь солнечный контейнер: 500 × 500 × 4 ≈ 977 КБ
• только двенадцать лучей: 250 × 40 × 4 × 12 ≈ 469 КБ

Потребление памяти будет уменьшено в два раза. Для этого мы должны анимировать каждый луч отдельно , а не анимировать контейнер. Таким образом, только изображения лучей будут отправлены в графический процессор; промежутки между ними не будут занимать никаких ресурсов.

Нам пришлось бы немного усложнить нашу разметку, чтобы анимировать лучи независимо, и CSS был бы здесь большим препятствием. Мы уже использовали преобразование для начального вращения лучей, и мы должны запустить анимацию под точно таким же углом и сделать поворот на 360 градусов. По сути, нам нужно было бы создать отдельный раздел @keyframes для каждого луча, и это много кода для передачи по сети.

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

Новая анимация выглядит так же, как и предыдущая, но в два раза меньше потребляемой памяти.

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

Попробуем уменьшить размер текстуры на 10%. Физический размер луча будет 250 × 0,9 × 40 × 0,9 = 225 × 36 пикселей. Чтобы луч был похож на 250 × 20, нам нужно увеличить его на 250 ÷ 225 ≈ 1,111.

Мы добавим строку в наш код - background-size: cover для .sun-ray - так, чтобы фоновое изображение автоматически изменяло размер элемента, и мы добавим transform: scale (1.111) для анимации луча.

Обратите внимание, что мы изменили только размер элемента; размер изображения PNG остается прежним. Прямоугольник, созданный элементом DOM, будет отображаться как текстура для графического процессора, а не PNG-изображения.

Размер новой композиции солнечного луча на графическом процессоре теперь составляет 225 × 36 × 4 × 12 ≈ 380 КБ (это было 469 КБ). Мы сократили потребление памяти на 19% и получили очень гибкий код, в котором мы можем поиграть с уменьшением масштаба, чтобы получить оптимальное соотношение качества и памяти. В результате, увеличивая сложность анимации, которая на первый взгляд кажется такой простой, мы сократили потребление памяти в 977 ÷ 380 ≈ 2,5 раза!

JavaScript позволяет работать с процессором и может быть заблокирован тяжелыми вычислениями. Если вы хотите поближе познакомиться с оптимизацией анимации на GPU, я предлагаю небольшую домашнюю работу. Вилка Codepen солнечных лучей и заставить анимацию солнечных лучей работать полностью на графическом процессоре, но при этом быть настолько же эффективной и гибкой, как и в оригинальном примере. Разместите свой пример в комментариях, чтобы получить обратную связь.

Уроки выучены

Мои исследования по оптимизации страницы Chaos Fighters заставили меня полностью переосмыслить процесс разработки современных веб-страниц. Вот мои основные принципы:

• Всегда договаривайтесь с клиентом и дизайнером обо всех анимациях и эффектах на сайте. Это может сильно повлиять на разметку страницы и улучшить компоновку.
• Следите за количеством и размером составных слоев с самого начала, особенно созданных с помощью неявного композитинга. Панель «Слои» в инструментах разработки вашего браузера - ваш лучший друг.
• Современные браузеры активно используют композитинг не только для анимации, но и для оптимизации рисования элементов страницы. Например, position: fixed, а элементы iframe и video используют композитинг.
• Размер составных слоев, вероятно, будет более важным, чем количество слоев. В некоторых случаях браузер будет пытаться уменьшить количество составных слоев (см. Раздел «Сжатие слоев» в « GPU Ускоренное наложение в Chrome «); это предотвращает так называемый «взрыв слоя» и уменьшает потребление памяти, особенно когда слои имеют большие пересечения. Но иногда такая оптимизация оказывает негативное влияние, например, когда очень большая текстура потребляет гораздо больше памяти, чем несколько небольших слоев. Чтобы обойти эту оптимизацию, я добавляю небольшое уникальное значение translateZ () к каждому элементу, например translateZ (0,0001px), translateZ (0,0002px) и т. Д. Браузер определит, что элементы находятся в разных плоскостях в трехмерном пространстве. и, таким образом, пропустить оптимизацию.
• Вы не можете просто добавить transform: translateZ (0) или will-change: transform к любому случайному элементу, чтобы фактически улучшить производительность анимации или избавиться от визуальных артефактов. Компоновка GPU имеет много недостатков и компромиссов, которые необходимо учитывать. Если не использовать экономно, композитинг в лучшем случае снизит общую производительность, а в худшем - аварийно завершит работу браузеров.

Позвольте мне напомнить вам о большом отказе от ответственности: нет официальной спецификации для компоновки GPU, и каждый браузер решает одни и те же проблемы по-своему. Некоторые разделы этой статьи могут устареть через несколько месяцев. Например, разработчики Google Chrome изучают способы снижения накладных расходов при передаче данных между процессорами и графическими процессорами, включая использование специальной общей памяти с нулевыми издержками на копирование. А Safari уже может делегировать отрисовку простых элементов (таких как пустой элемент DOM с цветом фона) графическому процессору вместо создания его изображения в ЦП.

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

Похожие

Комментарии