en fait quand le moteur a fini de traçer son image, il indique au Direct3D/OpenGL, qu'il doit basculer entre le "front" et le "back" buffer.
le "front" buffer est l'image que tu voies, le "back" est l'image qui est en court de traçage.
lorsque tu as fini de traçer une image, tu bascules entre les deux, comme ça, en travaillant sur deux buffers d'image, on ne voit pas l'image se construire polygone par polygone (ok fo avoir de bon yeux
).
la vsync, synchronisation avec le retour balayage du moniteur, fait que ce basculement de "buffer" se fait quand le flux d'électrons du tube du moniteur est en train de remonter d'en bas à droite vers en haut à gauche du tube.
vsync désactivée, le basculement se fait à n'importe quel moment, ce qui fait que tu peux voir un déchirement à l'écran, du "tearing".
imagine deux images, une rouge, une verte, au basculement, avec la vsync, tu vois deux images l'une après l'autre rouge puis verte.
sans la vsync, tu as l'impression d'avoir une image avec une portion rouge et une portion verte.
le désavantage de la vsync, c'est que le "traçage" de l'image suivante est bloqué tant que l'on a pas basculé d'image.
dans le cas ou l'on souhaite conserver la Vsync, le TrippleBuffering viens, et là on utilise deux "back" buffers.
comme ça quand on sait que l'on attends la vsync pour basculer entre le "front" et le premier "back", on peut commençer à traçer l'image suivante dans le deuxième "back".
------
le prerenderlimit, doit jouer au niveau driver pour tamponner le flux de commande venant d'un appli 3d pour N images...
ceci afin de maximizer le rendement (via du parallélisme, pendant que l'on traçe, on accepte les commandes de traçage de l'image suivante).
-------
par exemple les benchmarks comme 3dmark font sauter cette optimisation qui pourrait fausser les mesures de fps, en "verrouillant" le back-buffer (bon c'est un terme d3d).
Message édité par bjone le 17-09-2002 à 20:55:35