Почему включение аппаратного ускорения в CSS3 замедляет производительность?
Я перемещаю 6000 маленьких элементов div в эксперименте css3, используя переход top: 0
в top: 145px
для проверки производительности.
Использование аппаратного ускорения не работает в Google Chrome.
Если я включу аппаратное ускорение с помощью translateZ(0)
производительность становится ужасной.
- Размер шрифта слишком большой, чтобы соответствовать кешу
- Режим рендеринга программ - WPF
- Работа над Canvas.clipPath (), которая больше не поддерживается в android
Почему это так?
Вот мой пример кода: http://dl.dropboxusercontent.com/u/17844821/tmp/hwtest.html
Обновление (2014-11-13): Поскольку этот вопрос все еще привлекает внимание, я хотел бы указать, что сама проблема по-прежнему существует, хотя упомянутое заикание больше не может быть видно в предоставленной демонстрации на современном оборудовании . Старые устройства могут по-прежнему видеть проблемы с производительностью.
Я всегда добавляю:
-webkit-backface-visibility: hidden; -webkit-perspective: 1000;
При работе с 3d-преобразованием. Даже «поддельные» 3D-преобразования. Опыт говорит мне, что эти две линии всегда улучшают производительность, особенно на iPad, а также на Chrome.
Я тестировал ваш пример, и, насколько я могу судить, он работает.
Что касается «почему» части вашего вопроса … я не знаю. 3D-преобразование – это молодой стандарт, поэтому реализация изменчивая. Вот почему это свойство с префиксом: для бета-тестирования. Кто-то может заполнить отчет об ошибке или вопрос и провести расследование команды.
Редактировать за 19 августа 2013 года :
Регулярная активность в этом ответе, и я просто потерял час, обнаружив, что IE10 также нуждается в этом. Поэтому не забывайте:
backface-visibility: hidden; perspective: 1000;
Причина, по которой анимация была медленнее, когда вы добавили hub ( translateZ(0)
), – это то, что каждое нулевое 3D-преобразование создает новый слой. Когда слишком много этих слоев, производительность рендеринга страдает, потому что браузеру нужно отправить много текстур на GPU.
Проблема была замечена в 2013 году на домашней странице Apple, которая злоупотребляла взломом с нулевым преобразованием. См. http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/
ОП также правильно заметил объяснение в своем комментарии :
Перемещение нескольких больших объектов более эффективно, чем перемещение большого количества мелких предметов при использовании 3D-ускорения, потому что все слои с 3D-ускорением должны быть перенесены на GPU и обратно. Поэтому, даже если GPU выполняет хорошую работу, передача многих объектов может быть проблемой, поэтому использование ускорения GPU может не стоить того.
Интересно. Я пробовал играть с несколькими вариантами about:flags
, в частности эти:
Компиляция графического процессора на всех страницах Использование графического ускорения композиций на всех страницах, а не только те, которые include в себя слои с ускорением GPU.
Ускоренный чертеж с графическим процессором Включите графический ускоритель для рисования содержимого страницы при включении компоновки.
GPU Accelerated Canvas 2D Позволяет повысить производительность тэгов canvasа с помощью 2D-контекста путем рендеринга с использованием оборудования графического процессора (GPU).
Включили те, попробовали и потерпели неудачу с включенным тиккетом (как и вы). Но потом я заметил еще один вариант:
Счетчик FPS Показывает фактическую частоту кадров страницы в кадрах в секунду, когда аппаратное ускорение активно .
Учитывая выделение в описании флага, я бы предположил, что аппаратное ускорение было, по сути, для меня, даже без отмеченного флажка, поскольку я видел счетчик FPS с включенными выше параметрами!
TL; DR: аппаратное ускорение – это, в конце концов, предпочтение пользователя; заставляя его с фиктивным translateZ(0)
будет вводить избыточные накладные расходы, что приводит к более низкой производительности.
Проверьте хром: // флаги в хроме. В нем говорится:
«Когда включена компоновка с резьбой, ускоряемые анимации CSS выполняются в streamе компоновки. Тем не менее, производительность может увеличиваться с помощью ускоренных анимаций CSS, даже без streamа композитора».
Мой опыт заключается в том, что графические процессоры обычно не быстрее для всех видов графики. Для очень «базовой» графики они могут быть медленнее.
Возможно, вы получили другой результат, если бы вы вращали изображение – вот что такое, что графические процессоры хороши в
Также рассмотрим, что translateZ (0) – операция в 3 измерениях, а смена верхней или левой – двумерная операция
Я видел две демонстрации, я думаю, что знаю причину, которую вы смутили:
- Элементы анимации Не используйте левую или верхнюю часть для изменения местоположения, попробуйте использовать -webkit-transform;
- Все дочерние элементы должны включать аппаратное ускорение, например, использовать translateZ () или translate3D;
- FPS измеряет гибкость анимации, ваша демо FPS в среднем составляет только 20FPS.
Выше, только личное мнение, спасибо!