Оптимизация производительности анимации в WebKit на Linux

Как оптимизировать скомпилированный браузер WebKit, чтобы максимально использовать преимущества GPU?

Фон

Моя команда и я работаем над настройкой ящика Linux (CentOS) для отображения полноэкранного HTML с плавной анимацией с поддержкой CSS. Коробка имеет более чем достаточную мощность графического процессора и процессора и способна легко воспроизводить эти анимации в Chromium.

Однако мы пытаемся использовать чистый WebKit для рендеринга этих анимаций как с помощью WebKitGTK+ в Python, так и путем компиляции WebKit в упрощенном браузере из источника.

Текущее состояние

В обоих "чистых" приложениях веб-кит анимации значительно медленнее, чем у Chromium, что заставляет нас почесывать головы, чтобы ответить на то, что точно отличается от них. Мы понимаем, что Chromium использует Blink, вилку WebKit, и в настоящее время мы полагаем, что разница в производительности связана с тем, что браузеры Chromium, Safari и другие браузеры на основе WebKit используют свой собственный графический компонент, который отделен от WebKit и самого Web Core, основываясь на том, что мы читали.

Было бы здорово, если бы мы могли настроить нашу сборку WebKit, чтобы выполнить даже половину спецификации того, что мы видим в Chromium, но мы не знаем, с чего начать.

Мне интересно...

Правильно ли наше предположение о отдельном графическом компоненте?
Какие существуют опции для оптимизации производительности CSS-анимации в "чистом" браузере WebKit, таком как наш?

Ответ 1

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

В настоящее время большинство современных браузеров поставляются с аппаратным ускорением. Они будут использовать его, когда видят, что DOM выиграет от этого. Сильным индикатором является 3D-преобразование.

Допустим, вы хотите разместить свою DOM с абсолютной позицией и поднять ее выше родительского контейнера. Вместо этого вы можете использовать -webkit-transform: translate3d(10px,10px,10px); Это будет разрешено в 3D-рендеринг, даже если мы не анимируем элемент вообще. Даже если вы установите нулевые значения, оно все равно вызовет ускорение графики.

СОВЕТ Если вы видите мерцание, попробуйте добавить -webkit-backface-visibility: hidden; и -webkit-perspective: 1000;

Теперь давайте поговорим об основах CSS

Вы должны знать, что самое главное, как браузеры ПРОЧИТАЛИ ваши селектор CSS, заключается в том, что они читают их справа налево. Это означает, что в селекторе ul > li img[alt="test.png"] первое, что интерпретируется, - img[alt="test.png"]. Первая часть также упоминается как "селектор ключей".

Итак, во-первых, идентификаторы наиболее эффективны, оставляя универсалии наименее. Таким образом, вы можете переписать код CSS, заменяющий глобальные (когда это не нужно) с идентификаторами.

Другим способом замедления работы браузера является добавление глобального выбора. (div # my-div) Что-то, что Chrome делает по умолчанию в режиме проверки. Это ПОЛНОСТЬЮ замедлит ваш браузер.

Безусловно, худший случай - селектор потомков. Даже селектор, который терпит неудачу (когда ваш селектор не соответствует чему-либо) лучше, чем html body div ul li a { }

Еще одна вещь, которая чрезвычайно полезна и чиста, - это селектор CSS3 (: последний-ребенок). Даже если эти селекторы помогают нам и облегчают нашу жизнь, они разорвут ваш браузер. Возможно, вы не заметите каких-либо различий в производительности на небольшом приложении, но когда вы представите их в Enterprise Applications, вы заметите, что они замедляют ваш рендеринг.

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

Также вы можете проверить интересный тест здесь.

Теперь, когда я думаю об этом, я должен начать с основ CSS. Ну, надеюсь, я немного помог вам с вашим Проектом. ура

Ответ 2

Согласно статье Гила Эрнандеса, CSS-анимации, трансляции и переходы не ускоряются автоматически с использованием графического процессора, а вместо этого выполняются из браузера медленного механизма рендеринга программного обеспечения. Итак, что именно заставляет браузер переключаться на режим GPU? Многие браузеры обеспечивают ускорение GPU с помощью определенных правил CSS.

Пример:

.cube {
   -webkit-transform: translate3d(250px,250px,250px)
   rotate3d(250px,250px,250px,-120deg)
   scale3d(0.5, 0.5, 0.5);
}