Pourquoi l’activation de l’accélération matérielle dans CSS3 ralentit-elle les performances?

Je déplace 6000 petits éléments div dans une expérience CSS3 en utilisant une transition de top: 0 à top: 145px pour tester les performances.

L’utilisation d’ aucune accélération matérielle s’exécute en douceur sur Google Chrome.

Si j’active l’accélération matérielle via translateZ(0) performances deviennent horribles.

Pourquoi est-ce si?

Voici mon exemple de code: http://dl.dropboxusercontent.com/u/17844821/tmp/hwtest.html


Mise à jour (2014-11-13): Étant donné que cette question attire toujours l’attention, je voudrais souligner que le problème lui-même semble toujours exister, bien que le bégaiement mentionné ne soit plus visible dans la démonstration fournie sur le matériel moderne . Les appareils plus anciens peuvent toujours rencontrer des problèmes de performances.

J’ajoute toujours:

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

Lorsque vous travaillez avec la transformation 3D. Même “faux” transformations 3D. L’expérience me dit que ces deux lignes améliorent toujours les performances, notamment sur iPad mais aussi sur Chrome.

J’ai testé sur votre exemple et, pour autant que je sache, ça marche.

En ce qui concerne la partie “pourquoi” de votre question … je ne sais pas. La transformation 3D est un standard jeune, la mise en œuvre est donc instable. C’est pourquoi il s’agit d’une propriété préfixée: pour les tests bêta. Quelqu’un pourrait remplir un rapport de bogue ou une question et demander à l’équipe d’enquêter.

Modifier le 19 août 2013 :

Il y a une activité régulière sur cette réponse, et je viens de perdre une heure à trouver que IE10 en avait également besoin. Alors n’oublie pas:

 backface-visibility: hidden; perspective: 1000; 

L’animation de la raison était plus lente lorsque vous avez ajouté le hack de transformation null ( translateZ(0) ): chaque transformation 3D nulle crée un nouveau calque. Lorsque ces couches sont trop nombreuses, les performances de rendu en pâtissent car le navigateur doit envoyer beaucoup de textures au processeur graphique.

Le problème a été remarqué en 2013 sur la page d’accueil d’Apple, qui a abusé du hack de transformation null. Voir http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/

L’OP a également remarqué correctement l’explication dans son commentaire :

Déplacer quelques objects volumineux est plus performant que de déplacer beaucoup de petits objects lors de l’utilisation de l’accélération 3D, car toutes les couches accélérées en 3D doivent être transférées vers le GPU et le chemin du retour. Donc, même si le GPU fait du bon travail, le transfert de nombreux objects peut être un problème, de sorte que l’utilisation de l’accélération GPU pourrait ne pas en valoir la peine.

Intéressant. J’ai essayé de jouer avec quelques options à about:flags , en particulier celles-ci:

Composition GPU sur toutes les pages Utilise la composition accélérée par GPU sur toutes les pages, pas seulement celles qui incluent des calques accélérés par le GPU.

Dessin accéléré par GPU Activez le dessin accéléré par GPU du contenu des pages lorsque la composition est activée.

Tableau de bord accéléré par GPU 2D Permet d’améliorer les performances des balises de canevas avec un contexte 2D en effectuant un rendu à l’aide du matériel GPU (Graphics Processor Unit).

Activé ceux-ci, essayé et échoué lamentablement avec la case à cocher activée (comme vous l’avez fait). Mais alors j’ai remarqué encore une autre option:

Compteur FPS Affiche la fréquence d’images réelle d’une page, en images par seconde, lorsque l’accélération matérielle est active .

Compte tenu de la mise en évidence dans la description de l’indicateur, je suppose que l’accélération matérielle était en fait activée pour moi même sans la case à cocher cochée depuis que j’ai vu le compteur FPS avec les options ci-dessus activées!

TL; DR: l’accélération matérielle est finalement une préférence de l’utilisateur; le forcer avec translateZ(0) factice introduira une surcharge de traitement redondante donnant l’apparence de performances plus faibles.

Vérifiez chrome: // flags en chrome. Ça dit

“Lorsque la composition par thread est activée, des animations CSS accélérées s’exécutent sur le thread de composition. Cependant, il peut y avoir des gains de performances en cours d’exécution avec des animations CSS accélérées, même sans le thread du compositeur.”

Mon expérience est que les GPU ne sont généralement pas plus rapides pour tous les types de graphiques. Pour des graphiques très “basiques”, ils peuvent être plus lents.

Vous pourriez avoir obtenu des résultats différents si vous tourniez une image – c’est le genre de chose que les GPU sont bons à

Considérons également que translateZ (0) est une opération en 3 dimensions, alors que changer en haut ou à gauche est une opération en 2 dimensions

Je t’ai vu deux démos think Je pense que je connais la raison pour laquelle tu as confondu:

  1. Les éléments d’animation N’utilisez pas la gauche ou la partie supérieure pour modifier l’emplacement, essayez d’utiliser -webkit-transform;
  2. Tous les éléments enfants doivent activer l’accélération matérielle, par exemple, utilisez translateZ () ou translate3D;
  3. Le FPS mesure la fluidité de l’animation, votre FPS de démonstration en moyenne seulement 20FPS.

Ci-dessus, seulement un avis personnel, merci!