Современные веб-браузеры могут использовать вездесущий графический процессор (как на мобильном, так и на настольном ПК) для ускорения рендеринга страниц. Это особенно подходит для популярных функций CSS, таких как анимация , переход , прозрачность , трансформация и многие другие. Однако веб-разработчикам необходимо убедиться, что все фрагменты работают хорошо для достижения идеальных 60 кадров в секунду.
Давайте рассмотрим следующий пример Spinning Cub e, в котором трехмерное преобразование сочетается с анимацией по ключевым кадрам. Вы можете попробовать живую демонстрацию , которая даст что-то вроде следующего (анимированный GIF, простите за качество):
Этот пример является идеальным случаем для браузера для выполнения графического компоновки . Браузер захватит элементы DOM, связанные с каждой стороной куба, и отобразит их в виде текстур, находящихся на графическом процессоре (текстуру можно представить как прямоугольную область, содержащую значения пикселей). Каждая сторона получит свою собственную текстуру, поэтому в этой демонстрации у нас будет четыре текстуры. Этот процесс захвата пикселей и отправки их в качестве текстур необходимо выполнить только один раз , то есть в самом начале, перед началом любой анимации.
Что происходит в каждом кадре анимации? Нет необходимости в дорогостоящем рендеринге, рисование этих текстов в трехмерной перспективе. Браузер вычислит необходимую трехмерную матрицу для преобразования существующих текстур, чтобы каждая из них была правильно спроецирована. Процесс повторяется в серии бесконечно малых шагов, поэтому у пользователя создается впечатление, что куб вращается.
В старые времена, когда возможности компоновки графических процессоров не было, вся эта анимация будет довольно дорогой. Для каждого такта браузер (через базовый графический стек) должен непрерывно рисовать текст на каждой стороне с помощью разных проекционных матриц, что вряд ли является тривиальной задачей, особенно на платформах с ограниченной скоростью и мощностью.
Одним из важных ключевых аспектов успешного композитного графического процессора является оптимальное количество загрузки текстуры. В нашем примере выше, текст никогда не меняется, и, следовательно, браузер должен сделать захват и наложение текстуры только один раз. Как мы отлаживаем это? Это довольно легко, если вы используете Safari на OS X. Сначала запустите эту команду в терминале:
defaults write com.apple.Safari IncludeInternalDebugMenu 1
а затем снова запустить Safari. У вас будет дополнительное меню Debug . Потяните это меню, чтобы перейти к пункту меню « Рисование / объединение флагов», а затем убедитесь, что установлен флажок « Показать составные границы» . Перезапустите Safari. Теперь, если вы снова посетите демонстрацию вращающегося куба , Safari (через WebKit) отобразит некоторую дополнительную информацию. Вы получите цветную рамку для каждого элемента DOM, который получает свой собственный слой и, таким образом, отображается как текстура GPU. Однако самое главное здесь — это номер, показанный в углу. Указывает, сколько раз содержимое слоя обновлялось. Каждое обновление, возможно, является дорогостоящей операцией, поскольку включает передачу пикселей в графический процессор.
Чтобы минимизировать количество загружаемых текстур, вы можете анимировать или изменять только следующие свойства: прозрачность, преобразование и фильтр. Все остальное может вызвать обновление слоя. Например, посмотрите пример codepen.io/ariya/full/xuwgy, который постепенно меняет цвет фона поля между зеленым и синим. Вы можете добавить все больше и больше блоков, в какой-то момент вся анимация кажется действительно вялой. Если это работает на смартфоне или планшете, браузер перестанет отвечать на запросы, в некоторых случаях, в конечном итоге, произойдет сбой. Просмотр этого примера из Safari:
Как вы можете видеть, высокие цифры в углу каждой коробки страшны. Браузер занят воссозданием контента для этого слоя, потому что цвет изменился. На каждом шаге это приводит к тому, что тонны пикселей передаются в графический процессор. Это исчерпывает как шину памяти для графического процессора, так и видеопамять графического процессора. Это классический случай неоптимальной компоновки графических процессоров, и никакие объемные переводы не могут решить эту проблему.
Хотя выбор анимированных свойств кажется весьма ограниченным, это означает конец света. На самом деле, если сделать это осторожно, комбинации непрозрачности и трансформации достаточно для создания впечатляющих эффектов. Для вдохновения ознакомьтесь с демонстрационными материалами, такими как периодическая таблица three.js , CSS-освещение Photon , представление FPS , Montage MovieShow (показано ниже) и многие другие.
Воспользоваться преимуществами ускорения с помощью графического процессора — это больше, чем просто слепое применение заклинания «перевод 3D». Помните, что спортивный автомобиль не дает вам гарантии, что вы достигнете пункта назначения быстрее, чем кто-либо другой, вы все еще находитесь в зависимости от дорожной ситуации. Убедитесь, что трафик между процессором и графическим процессором не перегружен — это ключ к тому, чтобы браузер достиг оптимального баланса.
добавление
Для более полного понимания этого вопроса обратитесь к моему предыдущему докладу о пользовательском интерфейсе Fluid с аппаратным ускорением (прочитайте слайд-слайд , посмотрите 28-минутное видео на YouTube). Там я также объяснил обходной путь (читай: взломать), если вы все еще настаиваете на анимации цвета фона. Некоторые другие связанные статьи, которые вы можете прочитать:
- Netflix: WebKit в вашей гостиной
- GPU Ускоренное наложение в Chrome
- На Translate3D и Взломы Создания Слоя
- Firefox 4: аппаратное ускорение
- Выключение составления основного потока (OMTC) и почему это важно
- Оптимизация веб-контента в UIWebViews и веб-сайтов на iOS