Les LCD en retard à l'affichage sur les CRT ? Oui ! - version imprimable

Les LCD en retard à l'affichage sur les CRT ? Oui !
DiversEcrans
Publié le Vendredi 28 Juillet 2006 par Vincent Alzieu

URL: /articles/632-1/lcd-retard-affichage-crt-oui.html

Page 1 - Le retard en pratique, dans un jeu

Les LCD en retard à l’affichage sur les CRT ? Oui !

Un, puis deux, puis trois mails nous sont arrivés cette année via Behardware.com pour nous alerter : des rumeurs feraient état d’un retard des LCD sur les CRT à l’affichage. Si la chose se vérifiait, cela ferait encore un argument de poids pour que les gamers restent accrochés à leur écran à tube. Nous avons donc démarré avec un premier test pratique : lancement d’un jeu en mode clone sur un CRT Mitsubishi et sur le superbe LCD Dell 2407WFP. Franchement, on jurerait la synchronisation parfaite. Du moins à première vue. Car en rejouant la scène, en y prêtant plus attention, un point tout de même nous perturbait. Sans doute était-ce psychologique, mais l’écran à tube semblait parfois légèrement en avance sur l’autre.

Alors nous avons attrapé un appareil photo Canon. Ceux-ci, notamment, ont l’avantage de filmer avec une cadence intéressante, de 30 fps soit la moitié du taux de rafraîchissement de l’écran. La vidéo a confirmé l’impression : parfois les écrans sont synchrones, parfois l’écran Dell a une image de retard (sur la cadence des 30 fps de l’appareil photo, soit sans doute 2 images si l’on rapporte ça à la fréquence des écrans), parfois c’est carrément deux images de retard qu’a le 2407WFP.

Nous verrons toutefois plus loin que le retard varie considérablement d’un écran à l’autre. Nous l’avons mesuré sur toutes les technologies dont nous disposions : TN 2 et 3 ms, IPS 6, 8 et 16 ms, MVA 8 ms... Les retards varient, il existe néanmoins quelques rares LCD rapides, presque aussi réactifs que les CRT.

Le retard en pratique

Pour l’heure, nous en sommes à la vidéo réalisée avec notre CRT d’un côté, l’écran Dell de l’autre. Voici le type de situation que l’on rencontre :

Jusqu’ici tout va bien...

La plupart du temps le clonage est parfait. Et puis il y a les autres fois...

Un temps d’avance sur CRT

Le retard est clairement mis en évidence sur cette image. D’une part on voit à gauche, sur le CRT, que l’adversaire a recentré son tir et nous a ajusté, alors qu’à droite son shoot part de côté. Mais surtout, sur l’écran Mitsubishi il nous reste 110 balles dans le chargeur, contre 111 sur le LCD.

Bon, je tire où moi ?

Où est notre adversaire ? Au centre ou sur la gauche ? J’hésite, je tire ou je pointe ? Pour être honnête, ce genre de situation est rare et fugitif. Mais ça arrive. Sur un joueur normal cela ne devrait pas avoir de conséquence. Mais si vous êtes du genre professionnel du shoot, la simple possibilité que cette situation survienne risque d’être rédhibitoire pour l’écran. Heureusement qu’il est d’autres LCD plus rapides.

Dans le même genre, on se rend compte un temps plus tôt sur le CRT qu’on se fait tirer dessus. L’écart en temps n’est pas très important, mais on a toujours un léger retard – et donc une réaction forcément plus tardive sur LCD.

Un facteur de stress supplémentaire dans les scènes d’action

Cela introduit un autre facteur : le niveau de tension ne sera pas le même sur les deux écrans. Le son est indépendant de l’écran. Sur CRT, les bruits et l’image seront parfaitement synchronisés. Sur LCD, le bruit arrivera au mieux en même temps, parfois avec une image d’avance, parfois avec deux. Nous avons trouvé des LCD qui ont TOUJOURS deux images de retard.

Nous avons donc demandé l’avis d’un ingénieur du son dans le cinéma, qui nous a expliqué qu’un tel décalage est parfois recherché dans les films. Si le son arrive après l’image, cela diminue la tension des scènes. S’il arrive avant, ça l’augmente. Appliqué aux jeux, cela signifie que vous entendrez les tirs légèrement avant de les voir à l’image. Ce ne sera pas forcément conscient, mais votre cerveau s’en rendra compte... et générera un niveau de stress un peu supérieur. Avis aux amateurs de sensations fortes : on vous invite à prendre un LCD avec un maximum de retard !

Page 2 - Le retard chronométré sur 7 écrans

Le retard chronométré sur 7 écrans

Après la pratique voici un test plus précis : on mesure cette fois précisément, au millième de seconde près, l’éventuel retard des écrans plats. Nous nous sommes rendu compte de quatre points :
- le CRT n’est jamais en retard sur aucun duel face à un LCD
- le retard n’est pas lié à la fréquence de rafraîchissement : 60 ou 75 Hz, ça ne change rien.
- il n’est pas lié non plus à l’interface. Un écran ne sera pas plus rapide en DVI qu’en analogique. La double conversion du signal ne ralentit pas plus l’écran. D’ailleurs, il est bon de rappeler que les CRT sont tous analogiques.
- le retard est variable dans le temps. Du coup, nous avons choisi de prendre 10 mesures d’affiliée pour en sortir à chaque fois le retard min / max et surtout moyen.

Dans cet exemple, l’écran dell est en retard de 32 ms. C’est une valeur qui revient très couramment, qui correspond à deux images de retard.

Retard en ms comparé à notre CRT Mitsubishi de référence.
Mesure établie sur l’interface DVI, à 60 Hz.

Sauf exception, l’écran ViewSonic VX922, les 6 autres écrans affichent en moyenne de une à deux images de retard (60 Hz = 1 image dessinée toutes les 16,7 ms).

Maintenant, ce temps varie. Voici sur trois exemples les écarts (en ms) relevés sur 10 tests consécutifs, entre le CRT et les écrans nommés :

Voila qui redore le blason du VX922, que nous avions un peu malmené dans notre comparatif des 19 pouces.

Page 3 - 1 retard, + 1 retard, +... (souris, carte graphique...)

1 retard, + 1 retard, +... (souris, carte graphique...)

Ce retard aurait peu de conséquence s’il était isolé. En fait, il ne vient que conclure celui de toute une chaîne, qu’on devrait chercher à minimiser.

Ça commence avec les périphériques de saisie. Qu’on soit en souris filaire ou sans fil, aucun modèle ne réagit immédiatement. Les souris "normales" sont en principe limitées à une fréquence d’échange de 125 Hz sur le bus USB. Soit un échange toutes les 8 ms. Soit encore un retard systématique de 1 à 8 ms à chaque commande. Et encore, on parle là des bonnes souris. Nous en avons trouvées qui communiquaient bien moins souvent, on peut facilement atteindre les 16 ms de retard. Maintenant, une "nouvelle" génération de souris s’est affranchie de cette limite à 125 Hz et profite du plus haut débit offert par l’USB 2, pour monter sur certaines (Razer) à 1000 Hz. Soit une latence optimale de 1 ms. En fait, nos essais ont révélé une certaine instabilité de ces système. On ne reste jamais à 1000 Hz, le débit varie alors de 50 à 1000 Hz, avec une moyenne tout de même sensiblement supérieure aux 125 Hz des souris USB 1. La gamme gamer de Logitech atteint elle 500 Hz, elle aussi avec une certaine instabilité.

Vient ensuite la carte graphique. Là j’ai deux options...

1 : je ne me casse pas la tête, on part sur l’idée d’un processeur ultra puissant couplé à une carte graphique très haut de gamme. Bref, on minimise les temps de calcul, qu’on en vient même à négliger pour certains. Entre autre, j’estime que la carte graphique fournira toujours plus de 60 fps dans les jeux, et même 100 fps : ça m’arrange pour l’une des mesures à venir.

2 : je me rappelle que je suis sur Hardware.fr, que si moi je n’y connais rien en cartes graphiques j’ai deux monstres à mes côtés, Damien Triolet et Marc Prieur. Je leur en parle et... je regrette. Car ils me compliquent la vie. Forcément avec eux, on rentre dans les détails. Mon calcul est juste, oui mais si on veut être un peu précis... Je vous mets le début de leurs sombres pensées pour ceux qui veulent réfléchir un peu plus, compléter les calculs, les affiner et évaluer un peu mieux l’étendue des dégâts :

Une carte graphique utilise 2 buffers, un buffer dans lequel elle calcule l’image et un autre dans lequel est lue l’image à afficher. Une image ne peut donc commencer à être affichée qu’après avoir été entièrement calculée.

En Vsync OFF, quand la carte graphique a calculé l’image dans le buffer A, elle inverse les buffers A et B directement, peu importe si le buffer B était en train d’être lu en vue d’être affiché. Si c’était le cas, alors l’image affichée sera une moitié de l’image n-1 et une moitié de l’image n. On a donc deux morceaux d’images différentes, et de ce fait deux retards différents. Entre 2 rafraîchissements de l’écran, plusieurs images peuvent avoir été calculées si la carte graphique et le processeur sont très performants. Dans ce cas le retard induit par la carte graphique est compris entre 2x le temps de calcul de l’image et 1x le temps de calcul avec une différence possible entre différents blocs de l’image affichée. Tout dépend donc ici de la puissance de la carte graphique et du processeur.

En Vsync ON, ce problème est évité puisque les buffers A et B ne peuvent être inversés que quand l’écran vient d’être rafraîchit. Quand la carte graphique a calculé l’image dans le buffer A, elle attend d’arriver à ce moment avant d’inverser les buffers. Ensuite le buffer A devient le buffer B et vice versa. Sur un écran 60 Hz, le buffer B est lu 60 fois par seconde mais ça ne veut pas dire qu’il a été mis à jour 60 fois par seconde ! Si la carte graphique est toujours capable de calculer l’image en moins de 1/60ème de seconde, très bien, le retard induit sera toujours de 1/60ème de seconde. Si la carte graphique prend plus de temps, elle va terminer après la fin du rafraîchissement, seul moment où elle peut inverser les buffers, elle devra donc attendre le rafraîchissement suivant, ce qui veut dire qu’une même image va être affichée 2 fois. La première fois elle aura un retard de 2/60ème de seconde et la seconde fois de 3/60ème de seconde. Le problème est accentué par le fait que le temps de calcul d’une image est variable dans le jeu, on peut ainsi passer d’un retard de 1/60ème à 3/60ème en avançant dans la scène ce qui cause un décalage important en plus de la baisse de fluidité. En Vsync ON il est crucial d’avoir un système capable de tenir au moins autant de FPS que le taux de rafraîchissement. On ne passe pas de 60 à 50 FPS mais directement de 60 à 30 même si la moyenne peut le masquer.

Il est également utile de préciser que le moteur du jeu a lui aussi un rôle à jouer et que le triple buffering permet de réduire le décalage qui se produit en VSync ON mais au prix d’un retard plus élevé généralisé.

Bien, tout ça pour dire que vous pouvez compliquer le calcul suivant à l’envie, en changeant l’hypothèse de départ. Si ça vous amuse, vous pouvez tout reprendre en estimant que la carte graphique ne tiendra pas les 60 ou 100 fps supposés acquis dans mes exemples suivants. Mais pour ma part, j’ai retenu l’option 1...

Page 4 - Bilan : 3 cas, et conclusion

Retour à l’option 1 : la méthode simple

On aura la meilleure réactivité avec l’option du Vsync sur OFF : la carte envoie les informations à l’écran au fur et à mesure qu’elle les calcule. Toutefois, il y a toujours petit retard (moins d’une image) à l’affichage du fait des temps de calcul.

Le Vsync OFF est la solution optimale, le problème, c’est qu’il introduit des ruptures dans les images. Esthétiquement, c’est moins joli. Très souvent, sur les LCD surtout, on active donc la synchronisation de la carte avec l’écran : le moniteur n’affiche les images qu’une fois qu’elles sont entièrement calculées. C’est plus joli, mais cette fois on perd en débit d’image (on est alors limités à la fréquence de rafraîchissement du moniteur, soit 60 fps pour 60 Hz sur la plupart des LCD) et le retard augmente. On passe cette fois à deux images entières de retard (en moyenne).

Dernière solution, certains passent en Triple Buffering pour lisser le framerate. Cette solution de moins en moins utilisée fait passer cette fois le retard à 3 images (en moyenne) !

Et derrière vient l’écran. On néglige donc volontairement le temps de calcul du processeur pour simplifier les choses.

Bilan de la chaîne des retards, trois cas de figure

Au final, si l’on prend la solution optimale, on aura une souris Razer Copperhead, une carte graphique en V Sync OFF et un CRT. Le retard sera de 1 ms + 0.5 image (avec une fréquence à 100 Hz, ce sera 1/100/2 = 5 ms) + 0 = 6 ms. On a moins d’une image de retard, ça ne devrait pas être perceptible.

Solution classique : une bonne souris USB 1 (toutes les Microsoft, la plupart des Logitech, les Razer économiques) + V Sync ON + un LCD moyen, type l’écran Dell 2407WFP. On passe alors à 8 ms + 2 images (LCD = 60 Hz, soit 33 ms) + 24 ms = 65 ms. On a donc presque 4 images de retard !

Solution déconseillée : une souris lente + Triple Buffering + un écran lent (type Acer AL2032W). 16 ms + 3 images (3 x 16,7 = 50 ms) + 44 ms (plus long retard mesuré sur l’écran Acer) = 110 ms, soit 6,5 image de retard !!!

D’où vient ce retard ? Difficile de répondre avec certitude pour l’instant, il va nous falloir creuser le sujet. Néanmoins, cette constatation nous revoit directement à un précédent article : Des dalles à la carte : Mura, électronique, pixels morts... . Très certainement, la qualité de l’électronique doit jouer sur la réactivité des écrans. Et comme nous l’avions déjà noté, cette électronique a des conséquences directes sur la qualité des écrans. Elle joue sur la longévité des composants, sur la tenue des couleurs dans le temps, sur le taux de pixels morts et d’effet mura. Sans doute faut-il encore y ajouter ce souci de réactivité relevé sur la plupart des moniteurs. En tout cas, de notre côté, nous nous sommes trouvé un test de plus à ajouter à notre panoplie...

Merci à Marc et Damien pour leur grande aide... et leur patience.