Чому увімкнення апаратного прискорення в CSS3 уповільнює продуктивність?

Я переміщую 6000 маленьких елементів div в експерименті css3, використовуючи перехід від top: 0до top: 145pxдо тестової продуктивності.

Без використання апаратного прискорення в Google Chrome працює гладко.

Якщо я ввімкну апаратне прискорення за допомогою translateZ(0)продуктивності, це стає жахливо.

Чому це так?

Ось мій приклад коду: http://dl.dropboxusercontent.com/u/17844821/tmp/hwtest.html

Оновлення (13.11.2014): Оскільки це питання все ще привертає увагу, я хотів би зазначити, що сама проблема все ще існує, хоча згадане заїкання може бути вже не видно у наданій демонстрації на сучасному обладнанні . Старі пристрої все ще можуть бачити проблеми з продуктивністю.

Я завжди додаю:

-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;

При роботі з 3D-перетворенням. Навіть "фальшиві" 3D-перетворення. Досвід підказує, що ці два рядки завжди покращують продуктивність, особливо на iPad, а також на Chrome.

Я протестував на вашому прикладі, і, наскільки я можу зрозуміти, це працює.

Щодо частини вашого запитання "чому" ... я не знаю. 3D-перетворення є молодим стандартом, тому реалізація нестабільна. Ось чому це префіксована властивість: для бета-тестування. Хтось може заповнити звіт про помилку або запитання і попросити команду провести розслідування.

Редагувати за 19 серпня 2013 року :

З цією відповіддю регулярно проводяться заняття, і я просто втратив годину, переконавшись, що IE10 також це потрібно. Тож не забувайте:

backface-visibility: hidden;
perspective: 1000;

Причиною того, що анімація була повільнішою, коли ви додали нульове перетворення hack ( translateZ(0)), є те, що кожне нульове 3D-перетворення створює новий шар. Коли цих шарів занадто багато, продуктивність візуалізації страждає, оскільки браузеру потрібно надіслати багато текстур на графічний процесор.

Проблема була помічена в 2013 році на домашній сторінці Apple, яка зловживала хакером нульової трансформації. Див. Http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/

Оператор також правильно помітив пояснення у своєму коментарі :

Переміщення кількох великих об'єктів є більш продуктивним, ніж переміщення великої кількості дрібних предметів при використанні 3D-прискорення, оскільки всі шари, прискорені 3D, повинні бути перенесені на графічний процесор і шлях назад. Отже, навіть якщо графічний процесор робить хорошу роботу, передача багатьох об’єктів може бути проблемою, так що використання прискорення графічного процесора може не коштувати того.

Цікаво. Я спробував пограти з кількома варіантами about:flags, зокрема такими:

Композитування GPU на всіх сторінках Використовує GPU-прискорене компонування на всіх сторінках, а не лише на тих, що включають прискорені GPU шари.

GPU Accelerated Drawing Увімкніть GPU прискорене малювання вмісту сторінки, коли увімкнено компонування.

GPU Accelerated Canvas 2D Уможливлює більш високу продуктивність тегів полотна у 2D-контексті завдяки отрисуванню за допомогою апаратного забезпечення графічного процесора (GPU).

Увімкнув ті, спробував і невдало провалився з увімкненою галочкою (так само, як і ти). Але тоді я помітив ще один варіант:

Лічильник кадрів в секунду Показує фактичну частоту кадрів сторінки в кадрах на секунду, коли активно апаратне прискорення .

Беручи до уваги основний момент в описі прапора, я припускаю, що апаратне прискорення насправді було включене для мене навіть без позначеного прапорця, оскільки я побачив лічильник FPS з увімкненими вище опціями!

TL; DR: апаратне прискорення, зрештою, є перевагою користувача; примусове використання манекена translateZ(0)призведе до надмірних накладних витрат на обробку, що дасть вигляд меншої продуктивності.

Перевірте chrome: // прапори в chrome. Він говорить

"Коли ввімкнено різьбове композитування, прискорені анімації CSS працюють на потоці композитування. Однак, може бути прискорення продуктивності, що працює з прискореними анімаціями CSS, навіть без потоку композитора."

Мій досвід полягає в тому, що графічні процесори, як правило, не швидші для всіх видів графіки. Для дуже "базової" графіки вони можуть бути повільнішими.

Можливо, ви отримали інший результат, якби обертали зображення - це те, у чому хороші графічні процесори

Також враховуйте, що translateZ (0) - це тривимірна операція, тоді як зміна верхньої чи лівої - це двовимірна операція

Я бачив вас двох демо-версій ， Думаю, я знаю причину, з якої ви заплутали:

1. Елементи анімації Не використовуйте лівий або верхній для зміни місця розташування, спробуйте використати -webkit-transform;
2. Усі дочірні елементи повинні вмикати апаратне прискорення, наприклад використання translateZ () або translate3D;
3. FPS вимірює плавність анімації, ваша демонстраційна FPS в середньому становить лише 20 FPS.

Вище, лише особиста думка, дякую!