Ce que cherche le scan des saccades

Ce qu'il fait

Le scan lit ce que Windows et tes pilotes ont déjà enregistré, et signale les choses connues pour produire une saccade que tu sens passer :

des pilotes qui ont gardé un cœur du processeur assez longtemps pour coûter une image
un écran qui tourne en dessous de la fréquence de rafraîchissement qu'il sait faire
des réglages d'alimentation qui laissent un cœur descendre à une fréquence dont il ne remonte pas vite
du travail d'arrière-plan planifié à une priorité qui entre en concurrence avec un jeu
des réglages laissés derrière lui par un autre outil

Chaque constat dit ce qui a été mesuré, pourquoi ça compte et — quand il y en a une — ce qu'il faut faire.

Les réglages qui ont changé

Chaque scan note aussi quelques réglages que les mises à jour sont connues pour modifier sans demander : la vitesse de la mémoire (un profil XMP/EXPO), l'intégrité de la mémoire, le plan d'alimentation, la planification GPU à accélération matérielle, les règles de priorité de lancement posées par w0a et la version du pilote graphique. La note reste sur cet ordinateur, dans %LocalAppData%\w0a\settings-drift.json. Quand un scan suivant trouve l'un d'eux déplacé dans le sens qui peut coûter à un jeu, ou un nouveau pilote graphique, une seule carte dit ce qui a changé, depuis quand, et si Windows a été mis à jour dans le même intervalle. Rien n'est remis en place : si tu as fait le changement toi-même, il n'y a rien à faire. La carte disparaît après 14 jours ou dès que le réglage est revenu. Le premier scan ne fait que prendre la note ; il n'y a rien à comparer avant le deuxième.

Ce qu'il ne fait pas

Il ne devine pas. Si rien de mesurable ne cloche, il le dit au lieu de remplir la page de conseils génériques. Un scan qui trouve dix problèmes à chaque fois te vend les solutions, il ne diagnostique pas la machine.

Il ne voit qu'en partie à l'intérieur d'un jeu. La compilation des shaders, une ressource chargée depuis un disque lent, une saccade côté serveur dans une partie en ligne — ça donne la même sensation et ça ne laisse presque aucune trace ici. Mais si tu as des passages de benchmark enregistrés, le scan s'en sert comme preuve : les images mesurées nettement plus lentes que leurs voisines apparaissent comme un constat à part entière. Si le scan est propre et que tu saccades quand même dans un jeu précis, c'est une information vraiment utile : la cause est dans le jeu, pas dans le système.

Lire les étiquettes

Chaque constat porte l'un de quatre mots, et il n'y a aucun pourcentage :

PROUVÉ — mesuré sur cette machine, significatif, et il vaut la peine d'agir
PROBABLE — le mécanisme a été mesuré ou observé sur cette machine ; on n'a pas mesuré si c'est bien ce que tu ressens
CANDIDAT — présent et connu pour pouvoir causer des saccades, mais rien ici ne prouve que ça l'a fait
NON VÉRIFIÉ — la règle n'a pas pu s'exécuter, donc on ne sait rien, ni dans un sens ni dans l'autre

Corrige d'abord les points PROUVÉ, puis relance le scan. Changer plusieurs choses d'un coup et mesurer ensuite ne t'apprend rien sur celle qui a aidé.

NON VÉRIFIÉ ne veut pas dire propre. Quand des règles n'ont pas pu s'exécuter, une carte donne le nombre exact — "N règle(s) sur M n'ont pas pu s'exécuter" — et la raison. Un scan avec des règles non exécutées n'a pas regardé ces causes-là du tout.

Le lancer pendant qu'un jeu est ouvert

La page s'ouvre sans risque en pleine partie. L'interrogation du matériel attend que le jeu se ferme — lire les capteurs prend un verrou dans le noyau graphique et provoquerait elle-même une saccade toutes les quelques secondes — pendant que la mesure ETW du temps de frame, elle, continue. Les règles sautées pour cette raison sont signalées comme sautées ; relance le scan jeu fermé pour les couvrir.