Mesurer les performances graphiques du navigateur

Ilmari Heikkinen

L'analyse comparative des images des navigateurs en bref: dessinez autant que possible tout en maintenant une fréquence d'images fluide. Une fois que la fréquence d'images baisse, vous savez combien vous pouvez dessiner par image. Fin du post. Personne ? OK, je vais en expliquer un peu plus.

Exemple de temps ! Voici un petit extrait de code avec une fonction tick d'analyse comparative. La fonction tick appelle une fonction draw avec une charge de dessin croissante jusqu'à ce que le dessin dure systématiquement plus de 33 ms.

var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
    var maximumFrameTime = 1000/30; // 30 FPS
    t = performance.now();
    var elapsed = t - previousTime;
    previousTime = t;
    if (elapsed < maximumFrameTime || slowCount < maxSlow) {
        if (elapsed < maximumFrameTime) {
            drawLoad+=10;
        } else {
            slowCount++;
        }
        draw(drawLoad);
        requestAnimationFrame(tick);
    } else {
        // found maximum sustainable load at 30 FPS
        document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
            maximumFrameTime + " ms");
    }
};
requestAnimationFrame(tick);

Voir l'exemple en direct sur jsFiddle

Vous pouvez constater que l'analyse comparative continue de dessiner de plus en plus jusqu'à ce qu'elle atteigne le point où elle ralentit. C'est un moyen simple et efficace de déterminer combien vous pouvez dessiner à une fréquence d'images fluide. Vous pouvez également insérer votre propre fonction de dessin dans l'exemple et effectuer une analyse comparative personnalisée.

Mises en garde et pièges courants lors de l'analyse comparative des images de navigateur

Si l'exemple ci-dessus est bien adapté, quelles sont les moins bonnes ? Les méthodes vous permettant d'effectuer une analyse comparative d'éléments sans rapport ou qui vous fournissent des métriques de performances étranges qui ne semblent avoir rien à voir avec la vitesse d'exécution de votre application. Ravi que vous posiez la question, voici les deux plus courantes que j'ai vues sur le Web.

Mesure du FPS maximal: dessinez un peu chaque image et mesurez le FPS. Il ne fonctionne pas bien pour mesurer les performances graphiques dans Chrome, car l'implémentation graphique sous-jacente est synchronisée avec la fréquence d'actualisation de l'écran (vous bénéficiez donc d'un maximum de 60 mises à jour d'écran par seconde). Mesurer la vitesse d'appel de dessin n'est pas non plus très utile, car le système de dessin de Chrome place vos commandes de dessin dans un tampon de commandes qui sera exécuté à la prochaine actualisation de l'écran.

L'utilisation de setTimeout pour mesurer les performances graphiques n'est pas une bonne idée. Dans les navigateurs, l'intervalle setTimeout est limité à 4 ms. Vous ne pouvez donc pas en profiter au maximum à 250 FPS. Auparavant, les navigateurs avaient des intervalles minimaux différents. Par conséquent, vous aviez peut-être un benchmark de dessin très fissuré qui affichait le navigateur A s'exécutant à 250 FPS (intervalle de 4 ms minimum) et le navigateur B s'exécutant à 100 FPS (intervalle de 10 ms minimum). De toute évidence, A est plus rapide ! Non ! Il se peut que B ait exécuté le code de dessin plus rapidement que A (par exemple, si A a pris 3 ms et B en 1 ms). Cela n'affecte pas le FPS, car la durée de dessin est inférieure à l'intervalle minimal setTimeout. Et si le navigateur s'affiche de manière asynchrone, tous les paris sont désactivés. N'utilisez la fonction setTimeout que si vous savez ce que vous faites.

Procédure à suivre dans ce cas

Une meilleure façon d'effectuer une analyse comparative consiste à utiliser une charge de dessin réaliste et à la multiplier jusqu'à ce que la fréquence d'images commence à diminuer. Par exemple, si vous écrivez un jeu descendant avec un terrain de carte de tuiles, essayez de dessiner la carte de tuiles à chaque image et vérifiez si elle s'exécute à 60 FPS. Si oui, augmentez la charge (dessinez le tilemap deux fois à chaque image, avec un espace entre les deux). Continuez d'augmenter jusqu'à ce que le FPS atteigne un nouveau niveau stable. Vous connaissez maintenant le nombre de calques de tilemap que vous pouvez dessiner par image.

Les applications graphiques n'ont pas tous les mêmes besoins. Vous devez donc écrire vos analyses comparatives en gardant cela à l'esprit. Mesurez les fonctionnalités graphiques que vous utilisez dans votre application. Lorsque vous constatez un scénario lent, essayez de réduire au maximum le code qui le reproduit (et envoyez un rapport de bug sur new.crbug.com si le processus devrait être plus rapide).

Pour savoir comment écrire du code graphique Web hautes performances, regardez la conférence Google I/O 2012 de Nat Duca et Tom Wiltzius, de l'équipe Chrome chargée des GPU.