Ik verplaats 10.000 kleine div-elementen in een css3-experiment van de bovenkant van de browserviewport naar de onderkant. Voor deze test gebruik ik 2 verschillende benaderingen:
- Met GPU-versnelling met behulp van
translate3D(x, y, z)oftranslateZ(0) - Geen GPU-versnelling door simpelweg de eigenschap
topin css aan te passen
Het gebruik van NEEhardware-acceleratie verloopt redelijk soepel in Google Chrome.
Als ik hardwareversnelling inschakel, worden de prestaties een stuk slechter. Het is zo erg dat de dozen niet eens meer gelijkmatig verdeeld zijn:
Met GPU/Hardware-versnelling:
Zonder GPU/Hardware-versnelling:
Vraag
Waarom is dat zo? Zou het gebruik van de GPU de prestaties niet moeten verbeteren?
Demo-applicatie
https://www.timo-ernst.net/misc/hwtest/
Bron
https://github.com/valnub/hwtest
Mijn hardware gebruikt voor test
- Apple Macbook Pro 15″ 2015-model
- CPU 2,8 GHz Intel Core i7
- 16 GB RAM
- macOS Big Sur 11.2
Update(2014-11-13): Aangezien deze vraag nog steeds de aandacht trekt, wil ik erop wijzen dat het probleem zelf nog steeds lijkt te bestaan, hoewel het genoemde stotteren misschien niet niet meer zichtbaar zijn in de meegeleverde demo op moderne hardware. Oudere apparaten kunnen nog steeds prestatieproblemen ondervinden.
*Update II(2021-02-17): het probleem blijft bestaan, maar u zult het aantal dozen dat in de demo wordt verplaatst, moeten verhogen op basis van de gebruikte hardware. Ik heb de gebruikersinterface van de demo-app gewijzigd, zodat je nu het aantal verplaatste boxen kunt aanpassen om een stotteranimatie voor je specifieke hardware te maken. Om het probleem te repliceren, raad ik aan om voldoende vakken te maken om stotteren te zien met GPU/hardware-versnelling ingeschakeld. Vink vervolgens het vakje aan en voer de test opnieuw uit zonder versnelling. De animatie zou vloeiender moeten zijn.
Antwoord 1, autoriteit 100%
Ik voeg altijd toe:
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
Bij het werken met 3D-transformatie. Zelfs “nep” 3D-transformaties. De ervaring leert me dat deze twee lijnen altijd de prestaties verbeteren, vooral op iPad maar ook op Chrome.
Ik heb je voorbeeld getest en, voor zover ik weet, werkt het.
Wat betreft het “waarom”-gedeelte van uw vraag… ik weet het niet. 3D-transformatie is een jonge standaard, dus de implementatie is schokkerig. Daarom is het een prefix: voor bètatests. Iemand kan een bugrapport of een vraag invullen en het team laten onderzoeken.
Bewerken per 19 augustus 2013:
Er is regelmatig activiteit op dit antwoord, en ik heb net een uur verloren toen ik ontdekte dat IE10 dit ook nodig had.
Dus vergeet niet:
backface-visibility: hidden;
perspective: 1000;
Antwoord 2, autoriteit 8%
De reden waarom de animatie langzamer was toen je de null-transformatie-hack toevoegde (translateZ(0)) is dat elke null 3D-transformatie een nieuwe laag creëert. Als er te veel van deze lagen zijn, gaan de weergaveprestaties achteruit omdat de browser veel texturen naar de GPU moet sturen.
Het probleem werd in 2013 opgemerkt op de homepage van Apple, die misbruik maakte van de nultransformatie-hack. Zie http://wesleyhales.com/blog/ 2013/10/26/Jank-Busting-Apples-Home-Page/
De OP heeft ook de uitleg correct opgemerkt in hun commentaar:
Het verplaatsen van weinig grote objecten is efficiënter dan het verplaatsen van veel kleine items bij gebruik van 3D-versnelling, omdat alle 3D-versnelde lagen moeten worden overgedragen naar de GPU en de weg terug. Dus zelfs als de GPU goed werk levert, kan de overdracht van veel objecten een probleem zijn, zodat het gebruik van GPU-versnelling misschien niet de moeite waard is.
Antwoord 3, autoriteit 6%
Interessant. Ik heb geprobeerd met een paar opties te spelen in about:flags, met name deze:
GPU-compositing op alle pagina’sMaakt gebruik van GPU-versnelde compositing op alle
pagina’s, niet alleen die met GPU-versnelde lagen.GPU-versneld tekenenGPU-versneld tekenen van pagina inschakelen
inhoud wanneer compositie is ingeschakeld.GPU Accelerated Canvas 2DMaakt betere prestaties van canvastags mogelijk
met een 2D-context door te renderen met behulp van Graphics Processor Unit (GPU)
hardware.
Ingeschakeld, geprobeerd en jammerlijk gefaald met het aankruisvak ingeschakeld (net als jij deed). Maar toen zag ik nog een andere optie:
FPS-tellerToont de werkelijke framesnelheid van een pagina, in frames per seconde,
wanneer hardwareversnelling actief is.
Gezien het hoogtepunt in de vlagbeschrijving, zou ik speculeren dat hardwareversnelling voor mij in feite was ingeschakeld, zelfs zonder het aangevinkte selectievakje, aangezien ik de FPS-teller zag met de bovenstaande opties ingeschakeld!
TL;DR:hardwareversnelling is uiteindelijk een gebruikersvoorkeur; forceren met dummy translateZ(0)introduceert redundante verwerkingsoverhead waardoor de schijn van lagere prestaties ontstaat.
Antwoord 4
Controleer chrome://flags in chrome. Er staat
“Als threaded compositing is ingeschakeld, worden versnelde CSS-animaties uitgevoerd op de compositing-thread. Er kunnen echter prestatieverbeteringen optreden met versnelde CSS-animaties, zelfs zonder de compositor-thread.”
Antwoord 5
Mijn ervaring is dat GPU’s over het algemeen niet sneller zijn voor alle soorten graphics. Voor zeer “basis” afbeeldingen kunnen ze langzamer zijn.
Misschien had je een ander resultaat gekregen als je een afbeelding had gedraaid – dat is waar GPU’s goed in zijn
Houd er ook rekening mee dat translateZ(0) een bewerking in 3 dimensies is, terwijl het veranderen van boven of links een tweedimensionale bewerking is
Antwoord 6
Ik heb jullie twee demo’s gezien， Ik denk dat ik weet waarom jullie in de war waren：
- De animatie-elementen Gebruik de linker- of bovenkant niet om de locatie te wijzigen, probeer de -webkit-transform;
- Alle onderliggende elementen moeten hardwareversnelling inschakelen, zoals translateZ () of translate3D gebruiken;
- FPS meet de vloeiendheid van animaties, je demo-FPS is gemiddeld slechts 20FPS.
Bovenstaande, alleen een persoonlijke mening, bedankt!