Perché l’triggerszione dell’accelerazione hardware nei CSS3 rallenta le prestazioni?

Sto spostando 6000 piccoli elementi div in un esperimento css3 usando una transizione top: 0 in top: 145px per testare le prestazioni.

L’utilizzo dell’accelerazione hardware senza intoppi gira su Google Chrome.

Se abilito l’accelerazione hardware tramite translateZ(0) prestazioni diventano orribili.

Perchè è così?

Ecco il mio codice di esempio: http://dl.dropboxusercontent.com/u/17844821/tmp/hwtest.html


    Aggiornamento (2014-11-13): Poiché questa domanda sta ancora attirando l’attenzione, vorrei sottolineare che il problema in sé sembra ancora esistere sebbene la balbuzie menzionata potrebbe non essere più visibile nella dimostrazione fornita sull’hardware moderno . I dispositivi precedenti potrebbero ancora riscontrare problemi di prestazioni.

    Aggiungo sempre:

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

    Quando si lavora con la trasformazione 3d. Anche le trasformazioni 3D “finte”. L’esperienza mi dice che queste due linee migliorano sempre le prestazioni, specialmente su iPad ma anche su Chrome.

    Ho fatto dei test sul tuo esempio e, per quanto posso dire, funziona.

    Per quanto riguarda la parte “perché” della tua domanda … non lo so. Le trasformazioni 3D sono uno standard giovane, quindi l’implementazione è instabile. Ecco perché è una proprietà prefissata: per il beta test. Qualcuno potrebbe compilare una segnalazione di bug o una domanda e far indagare la squadra.

    Modifica al 19 agosto 2013 :

    C’è una regolare attività su questa risposta, e ho appena perso un’ora per scoprire che anche IE10 ha bisogno di questo. Quindi non dimenticare:

     backface-visibility: hidden; perspective: 1000; 

    La ragione per cui l’animazione è stata più lenta quando hai aggiunto la trasformazione nulla nullo ( translateZ(0) ) è che ogni trasformazione 3D nullo crea un nuovo livello. Quando ci sono troppi di questi livelli, il rendering delle prestazioni soffre perché il browser deve inviare molte trame alla GPU.

    Il problema è stato notato nel 2013 sulla home page di Apple, che ha abusato del trucco di trasformazione nulla. Vedi http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/

    L’OP ha anche notato correttamente la spiegazione nel loro commento :

    Spostare pochi oggetti di grandi dimensioni è più performante che spostare molti piccoli oggetti quando si utilizza l’accelerazione 3D perché tutti i livelli con accelerazione 3D devono essere trasferiti alla GPU e al ritorno. Quindi, anche se la GPU fa un buon lavoro, il trasferimento di molti oggetti potrebbe essere un problema, quindi l’utilizzo dell’accelerazione GPU potrebbe non valerne la pena.

    Interessante. Ho provato a giocare con alcune opzioni in about:flags , in particolare queste:

    Compositing GPU su tutte le pagine Utilizza il compositing con accelerazione GPU su tutte le pagine, non solo quelle che includono i livelli con accelerazione GPU.

    Disegno accelerato GPU Abilita il disegno accelerato GPU dei contenuti della pagina quando il compositing è abilitato.

    GPU Accelerated Canvas 2D Abilita prestazioni più elevate dei tag canvas con un contesto 2D eseguendo il rendering utilizzando l’hardware Graphics Processor Unit (GPU).

    Abilitato quelli, provato e fallito miseramente con il tickbox abilitato (proprio come hai fatto tu). Ma poi ho notato ancora un’altra opzione:

    Contatore FPS Mostra la frequenza fotogrammi effettiva di una pagina, espressa in fotogrammi al secondo, quando l’accelerazione hardware è triggers .

    Considerato il momento saliente nella descrizione della bandiera, ipotizzerei che l’accelerazione hardware fosse, in effetti, per me anche senza la casella spuntata poiché ho visto il contatore FPS con le opzioni sopra triggerste!

    TL; DR: l’accelerazione hardware è, alla fine, una preferenza dell’utente; forzandolo con dummy translateZ(0) si introdurrà un overhead di elaborazione ridondante dando l’impressione di prestazioni inferiori.

    Controlla chrome: // flags in chrome. Dice

    “Quando la composizione in thread è abilitata, le animazioni CSS accelerate vengono eseguite sul thread di compositing.Tuttavia, potrebbero verificarsi miglioramenti nelle prestazioni con animazioni CSS accelerate, anche senza il thread di composizione.”

    La mia esperienza è che le GPU non sono generalmente più veloci per tutti i tipi di grafica. Per la grafica molto “base” possono essere più lenti.

    Potresti avere ottenuto risultati diversi se stavi ruotando un’immagine: questo è il genere di cose in cui le GPU sono buone

    Considera anche che translateZ (0) è un’operazione in 3 dimensioni, mentre il cambio in alto o a sinistra è un’operazione bidimensionale

    Ti ho visto due demo, penso di conoscere il motivo per cui ti sei confuso:

    1. Gli elementi dell’animazione Non utilizzare la sinistra o la parte superiore per modificare la posizione, provare a utilizzare -webkit-transform;
    2. Tutti gli elementi figlio devono triggersre l’accelerazione hardware come use translateZ () o translate3D;
    3. FPS misura la fluidità dell’animazione, la tua demo FPS in media solo 20FPS.

    Sopra, solo un’opinione personale, grazie!