Grafische performance meten met javascript.

[Thmz159]

Hallo,

Ik ben bezig aan een webapplicatie die nogal zwaar leunt op animaties (zowel CSS als jQuery). Het probleem is dat het op iets tragere pc's totaal niet vloeiend is. (op 1440x900 resolutie wel, op 1920x1080 niet op diezelfde pc, op Chrome) De code is al vrij ver geoptimaliseerd. Daarom dacht ik om bij het laden van de pagina een snelle "benchmark uit te voeren" die de grafische performance meet, en op basis van die gegevens enkele effecten in of uitschakelen.

Ik heb echter geen idee hoe ik zoiets maak. Het zou dus een stukje javascript/jQuery code zijn die mdv een of andere methode de grafische snelheid van de browser test.
Ik weet dat ik de snelheid kan meten met:

code:

var start = new Date().getTime();

for (i = 0; i < 50000; ++i) {
// do something
}

var end = new Date().getTime();
var time = end - start;
alert('Execution time: ' + time);

Maar hoe test ik specifiek de grafische kracht, en liefst compatibel met zoveel mogelijk browsers?
Ik dacht aan iets zoals een canvas een paar duizend keer drawen, maar dat werkt niet in alle browsers.

Nog beter zou natuurlijk zijn om gewoon de framerate van de animaties te kunnen uitlezen, maar daarvoor zijn nogal wat scripts nodig: https://github.com/mrdoob/stats.js

[NMe]

Ergens buiten de viewport (left: -100000 ofzo) iets animeren en na de animatie kijken hoe lang het duurde? Al heb ik geen idee of dat weggeoptimaliseerd wordt.

[ Voor 20% gewijzigd door NMe op 24-05-2013 19:26 ]

[Thmz159]

Het probleem is dat je (denk ik) bij het meten van de tijdsduur van een animatie niet echt veel weet over hoe vlot de animatie was (er worden gewoon veel frames overgeslagen).

[NMe]

Ook als je handmatig animeert met javascript?

Bovendien is het niet echt handig om zo hard op animaties te leunen. Kun je niet gewoon een beetje meer dimmen als het blijkbaar negatieve effecten heeft?

[TheNephilim]

Wellicht kun je proberen meer gebruik te maken van transitions in CSS3 en als door middel van modernizer terugvallen op JS animaties als de client geen CSS3 ondersteund. Dat lost je probleem niet echt op natuurlijk, maar maar je doelgroep (PC's waar het vloeiend werkt) wel groter.

[marko77]

Als het op trage desktops al een issue is zou ik toch een aantal zaken verwijderen, tabletbezoekers hebben nóg minder cpu power en dan gaat het een slechte ervaring opleveren.

[storeman]

Een canvas is niet echt representatief. Soms pakt een grafische kaart dit op. Animaties in de DOM zullen hier dan weer niet op leunen.

Ik vraag me vooral af wat voor animaties je toepast dat het zo zwaar leunt op het systeem. Ik kan me voorstellen dat sommige systemen de pagina nog aan het renderen zijn en dan al een animatie hebben draaien. Hierdoor wordt de processorload bijvoorbeeld hoog. Gebruik je veel transparency? Of complexe animaties?

[Thmz159]

Ik gebruik vooral veel box-shadows, wat transparency.. 't Is hoofdzakelijk ook een one-page pagina, dus een lange pagina waarbij de fixed menu items vanboven de pagina doen scrollen naar een bepaald punt. Vooral dat (automatisch) scrollen naar een bepaald punt van de pagina gaat schokkerig op een 9300M GS (1920x1080, op 1440x900 gaat het wel vloeiend.
Nu denk ik de grootste "vertrager" van de pagina gevonden te hebben. De fixed background zorgt dat in Chrome de pagina bij elke verschuiving word geredrawt. Zal daar eens wat mee experimenteren.

Ik probeer zoveel mogelijk met CSS animaties te werken maar die zijn niet overal goed toepasbaar en vooral dat scrollen naar een bepaald punt gaat (denk ik?) (nog) niet met CSS3.

[_Thanatos_]

Ook grafische kun je toch meten met de devtools in Chrome? Ik dacht (zo uit m'n hoofd) dat je nog extra dingen kunt aanzetten voor extra info, zoals het triggeren van relayouts, maar is dit niet al voldoende?

Best kans dat je op ieder "frame" van je animatie een relayout tegenkomt, en die zijn een performance hit. Een oplossing is *soms* om een translate op het te animeren element te zetten, zodat het op een aparte laag (nee niet een netscape <layer> maar een echte hardware rendering laag) wordt gerenderd. Moet de uiteindelijke browser dat wel hebben natuurlijk, maar alle moderne browsers behalve Opera renderen (deels) op de GPU, maar daar moet je soms dus wel wat voor doen.

[creator1988]

Gebruik gewoon de Chrome timeline, die kan ook je de redraws en de fps geven. Record de stuttering scroll en kijk wat er gebeurt (idee: onscroll handler ergens, die vuurt veel vaker dan je zou verwachten).

[_Thanatos_]

Toevallig vandaag even zitten spelen met die timeline. Maar ik heb zelf eigenlijk nog niet kunnen ontdekken hoe je kunt achterhalen waar iets vandaan komt. Ik met mijn grote mond ook

Het is heel handig, maar als iemand weet hoe je kunt achterhalen wát precies een (bijv) repaint of relayout veroorzaakt, is de TS er misschien mee geholpen. Ik kon zelf alleen achterhalen wanneer zo'n event gebeurt en hoe lang het duurt. Maar niet bijv welke CSS-regel ervoor verantwoordelijk was.