Comment est calculé le score Screen Test Pro

Voici la page de méthodologie. Rien n’y est simplifié à des fins commerciales ; si le code et cette page devaient un jour se contredire, c’est un bug et nous aimerions le savoir. (Version du benchmark au moment de la rédaction : 2.2.0.)

La question que pose le benchmark

La plupart des benchmarks graphiques figent la charge de travail et mesurent votre fréquence d’images. Le nôtre fait l’inverse : il fige le temps d’image visé et cherche la charge la plus lourde que votre appareil parvient à y maintenir. Le résultat est la « charge stable maximale » de chaque scène — 840 000 particules de nébuleuse, par exemple — et c’est à partir d’elle que le score est construit.

Pourquoi inverser ? Parce que les fréquences d’images saturent. Sur une machine rapide, une charge figée se cale sur la fréquence de rafraîchissement de l’écran et n’apprend rien ; la question intéressante est de savoir combien elle aurait pu en encaisser de plus. Chercher le plafond garde la mesure parlante depuis un téléphone de cinq ans jusqu’à un GPU de bureau, avec les mêmes scènes.

Ce qui est exécuté

Le profil Standard réunit cinq scènes Signature et une scène de contrôle, chacune sollicitant un axe différent :

Le rendu s’effectue avec un rapport de pixels plafonné (1,5×) et une taille interne limitée, si bien qu’un moniteur 5K et un portable 1080p affrontent des quantités de pixels comparables. L’aléatoire part d’une graine fixe et les pas de simulation sont figés : chaque exécution d’une version donnée fait exactement le même travail.

Comment la stabilité est jugée

Le moteur ne lit jamais un compteur de FPS. Il collecte des temps d’image depuis l’horloge d’animation du navigateur, par fenêtres d’environ 0,7 à 1,6 seconde, puis demande deux choses à chaque fenêtre :

• au plus 5% des images peuvent manquer le seuil de validation — 17,5 ms sur les écrans à synchronisation adaptative ; sur les écrans à fréquence fixe, le premier créneau de vsync sur lequel un travail dans les clous ne pourrait jamais tomber (25,0 ms à 60 Hz, 20,8 ms à 120 Hz) ;
• la moyenne tronquée — les 2% d’images les plus lentes écartées — doit rester dans 16,67 ms × 1,15.

Compter les manqués plutôt que de les noyer dans une moyenne permet qu’une pause du ramasse-miettes ne soit qu’une image ratée et non une fenêtre refusée ; la moyenne tronquée est le garde-fou qui empêche des manqués rares mais énormes de passer sur le seul décompte.

Pourquoi le seuil tient compte de votre écran : un moniteur fixe à 60 Hz peut présenter une image après 16,7 ms ou 33,3 ms et rien entre les deux, alors qu’une dalle de portable à synchronisation adaptative rend une image de 18 ms comme une image de 18 ms. Avec les tolérances de moyenne et de P95 de la 2.1.0, cet écart laissait les dalles adaptatives se contenter de 55 fps et valider, tandis que les moniteurs 60 Hz devaient tenir un vrai 60 : le même GPU obtenait un score plus faible sur un bureau que dans un châssis de portable. Avant la première scène, une sonde de cadence d’environ 600 ms observe donc la façon dont votre écran rend les images, et le critère s’ajuste pour que « tient 60 fps » soit la même affirmation dans toutes les catégories d’écran. Si la sonde constate que l’écran est bloqué sous 50 Hz environ — mode économie d’énergie, câble limité à 30 Hz — le test refuse de démarrer plutôt que de juger un GPU par une meurtrière à 30 Hz.

Le budget de 16,67 ms, lui, ne change jamais avec la fréquence de rafraîchissement. Un écran 120 Hz délivre des images sur une cadence de 8,3 ms quand la tâche est facile, mais valider n’exige que de rester dans le budget de 60 images par seconde : le matériel à haute fréquence est mesuré à armes égales, pas puni pour afficher ses images supplémentaires.

La recherche

Chaque scène parcourt une machine à états : preflight → baseline → warmup → ramp → bracket → confirm → anchor.

1. Baseline mesure une charge légère connue, qui devient la référence thermique.
2. Ramp multiplie la charge par environ 1,5 à chaque fenêtre validée, jusqu’à ce qu’une fenêtre échoue.
3. Bracket recherche la frontière par dichotomie entre la dernière réussite et le premier échec, jusqu’à réduire l’intervalle à environ 6%.
4. Confirm exige trois fenêtres validées consécutives à la charge candidate, dans une enveloppe de quatre. Une mauvaise fenêtre en début de phase reste rattrapable ; deux échecs consécutifs, ou une enveloppe épuisée sans trois réussites d’affilée, refusent le niveau et font redescendre la candidate.
5. Anchor rejoue la charge de référence. Si elle tourne désormais plus de 15% plus lentement qu’au départ, l’appareil a changé sous nos pieds — presque toujours une limitation thermique — et la scène est marquée dérive au lieu de faire comme si de rien n’était. L’ampleur du ralentissement est enregistrée elle aussi, pas seulement son existence.

Quelques images qui suivent chaque changement de charge sont écartées avant la reprise des statistiques : modifier la charge réalloue tampons GPU et cibles de rendu, et le navigateur facture cela comme une seule image très longue. Ce hoquet appartient à la transition, pas à la charge de travail ; la 2.1.0 le comptait, et sur la scène qui redimensionne sa cible de rendu à chaque barreau, il arrêtait la recherche bien en dessous de ce que le matériel tient réellement.

Chaque phase possède une limite de temps stricte (30 s par scène, 200 s par test). Passer l’onglet en arrière-plan met la mesure en pause et annule la fenêtre en cours ; un redimensionnement reconstruit la scène et refait la chauffe. Aucun chemin dans la machine à états ne peut se figer.

Des charges au score

Le calcul du score est une fonction pure des résultats enregistrés — vous pourriez le refaire à la main :

1. La charge stable maximale de chaque scène est divisée par la charge de référence de cette scène (une constante de calibration figée par version ; en gros, une bonne machine de bureau de 2025 tombe près de 1,0).
2. Les rapports ont un plancher à 0,05 et un plafond au sommet d’échelle propre à la scène — la charge la plus lourde que cette scène peut physiquement mettre en scène, placée environ 10× au-delà du matériel le plus rapide que nous ayons mesuré — si bien que le score ne cesse de monter que là où la mesure elle-même s’arrête. (La 2.1.0 écrêtait chaque scène à un 20× uniforme ; une M4 Max collait deux scènes contre ce plafond et une troisième contre le plafond de mesure, ce qui explique pourquoi des fleurons Apple sans rapport entre eux affichaient des totaux presque identiques.)
3. Les rapports écrêtés se combinent en une moyenne géométrique pondérée — les cinq scènes Signature portent l’essentiel du poids, le contrôle Canvas 2D 10%. Géométrique, parce que cela récompense l’équilibre : une machine bonne partout devance une machine légendaire sur un point et catastrophique sur un autre.
4. On multiplie par 1000, on applique la déduction de stabilité — 3% par scène marquée, que ce soit pour dérive ou pour un niveau non confirmé, dans la limite de 10% au total — et on arrondit.

Les paliers sont des seuils figés par version et, comme un score vaut 1000× la machine de référence, chacun en est réellement un multiple : Débutant sous 1000, Équilibré jusqu’à 2999, Rapide jusqu’à 8999, Extrême au-delà — soit moins de 1×, jusqu’à 3×, jusqu’à 9×, puis davantage. Ils existent pour donner une prise à un chiffre ; les scores par scène sont la vraie information.

Ce qui invalide une comparaison

• Des versions de benchmark différentes ne se comparent jamais. Changer un seul shader change la charge de travail ; la version inscrite sur votre fiche de résultat fait partie du score.
• Les tests de compatibilité (sans WebGL2) n’utilisent que les scènes Classiques et se notent dans leur propre espace, clairement étiqueté.
• Les tests bridés — toutes les scènes mesurées et confirmées, mais l’appareil a chauffé et ralenti — sont de vraies mesures de performance soutenue : ils se notent normalement et prennent place au classement des meilleurs scores avec le marqueur affiché sur la ligne. La plupart des tests sur téléphone atterrissent ici ; c’est de la physique, pas un défaut.
• Les tests dégradés — une scène qui n’a rien produit d’exploitable, ou un niveau que la recherche n’a jamais pu confirmer — donnent un plancher plutôt qu’un sommet : ils restent hors classement. Ils sont malgré tout conservés, toujours comptés dans les médianes agrégées, et la fiche de résultat indique quelle scène et pourquoi.
• Les deux marqueurs voyagent avec le test jusque dans notre jeu de données anonyme, de sorte que tout chiffre publié peut les distinguer.

Variation d’un test à l’autre, attentes chiffrées

Sur une machine branchée et au repos, deux tests consécutifs tombent généralement à quelques pour cent l’un de l’autre — c’est l’exigence de fenêtres consécutives de la phase de confirmation qui l’achète. Sur batterie, en mode économie d’énergie ou avec un châssis chaud, attendez-vous à plus de dispersion et probablement à un marqueur « bridé » ; ce n’est pas le benchmark qui a ses humeurs, c’est votre appareil qui offre réellement moins. Laisser refroidir et brancher avant un test est la chose la plus efficace à faire pour obtenir un chiffre représentatif. Ce qu’un benchmark de navigateur peut honnêtement mesurer explique quoi faire du chiffre une fois obtenu.