Ah, ça c'est peut être lié au problème de XFCE qui ne gérait pas, auparavant la synchronisation avec le « vertical blank » temps où autre fois le canon à électron remontait en haut et qui était le moment d'échanger les tampons d'affichage, ça revient au même aujourd'hui entre deux rafraîchissement des lcd/amoled/...
Du coup, sur des machine un peu pêchue, qui peuvent calculer plus d'une image par seconde, l'image suivante commence à être tracée alors que la première n'est pas affichée. ça oblige à plus de calcul que nécessaire (limité par la fréquence d'affichage) et ça crée les effets du type tearing (la nouvelle image calculée est au tiers ou moitié de l'écran, tandis que l'ancienne est en bas :).
Forcément dans ce cas, on a intérêt à limiter le calcul à la fréquence d'affichage... à se synchroniser sur elle. le CPU/GPU se repose après son boulot et avant l'affichage et rebosse un peu pour l'image suivante.
[^] # Re: Tearing
Posté par tao popus . En réponse au journal Coup de boost sur le pilote graphique Intel. Évalué à 2.
Ah, ça c'est peut être lié au problème de XFCE qui ne gérait pas, auparavant la synchronisation avec le « vertical blank » temps où autre fois le canon à électron remontait en haut et qui était le moment d'échanger les tampons d'affichage, ça revient au même aujourd'hui entre deux rafraîchissement des lcd/amoled/...
Du coup, sur des machine un peu pêchue, qui peuvent calculer plus d'une image par seconde, l'image suivante commence à être tracée alors que la première n'est pas affichée. ça oblige à plus de calcul que nécessaire (limité par la fréquence d'affichage) et ça crée les effets du type tearing (la nouvelle image calculée est au tiers ou moitié de l'écran, tandis que l'ancienne est en bas :).
Forcément dans ce cas, on a intérêt à limiter le calcul à la fréquence d'affichage... à se synchroniser sur elle. le CPU/GPU se repose après son boulot et avant l'affichage et rebosse un peu pour l'image suivante.