Salut à tous.
J'ai un gros problème de latence au niveau de l'affichage en utilisant OpenGL. J'en ai un peu parlé dans un autre post, mais je préfère en créer un nouveau pour voir si quelqu'un peut trouver une explication à mes mesures.
Ca fait quelques années que j'utilise openGL qui m'a servi à développer un soft de création de scènes en tout genre pour la recherche en neurosciences (ca c'est pour situer la chose). Afin d'être sûr de quand une scène visuelle est présentée à un sujet dont on va étudier son comportement et ses réactions, on doit pouvoir afficher le plus rapidement possible en fonction des interactions du sujet (joystick, souris, capteurs de mouvements, tablette graphique ... enfin tout ce qui peut faire interagir le sujet avec l'environnement).
Le soft est assez complet et fonctionne plutot bien à part un point sur lequel je me suis toujours cassé les dents : le délai d'affichage.
Le soft tourne sur un P4 3.6 Ghz, avec une Geforce 2 MX 400, sous WinXP. Certes la carte graphique n'est pas une bete de course, mais j'ai effectué des tests tres simples (affichage d'un simple carré blanc, sans texture, en fonction d'un simple trigger provenant du port parallèle, sur un bit donné (le pin10 au cas ou ...). Ce trigger est envoyé par une machine externe d'acquisition de données temps réel (de type AD Win Pro), qui fonctionne à vitesse tres élevée (quelques dizaine de KHz).
Le port parallele est "scruté" aussi vite que possible par le PC et, en renvoyant une valeur par le port parallèle vers la machine d'acquistion dès que l'on recoit le trigger, on peut mesurer dans un premier temps le délai de réaction lors de la réception de ce trigger. J'obtiens un délai bien inférieur à la milliseconde. Ceci pour vous expliquer que le trigger est tres vite capté par le pc avec tres peu de variabilité dans le temps (entre 0.01 et 0.08 millisecondes, c'est dire ...) et le tout mesuré par une machine externe précise et non Windows avec un quelconque compteur.
Bref le top d'affichage est envoyé par la machine temps réel, recu par le pc en quelques dizaines de microsecondes, le carré est précompilé par opengl en une display list (c'est pas tres utile pour un carré blanc mais comme j'ai pleins d'autres objets 2D et 3D, j'en fais diverses display lists dans le soft, mais dans ce cas de test je n'ai qu'un carré blanc en DL) et GLUT swap les buffers.
Pour tester le délai d'affichage j'ai placé une photo-diode sur l'écran qui envoie donc un signal électrique vers la machine temps réelle dès que le carré est affiché (la montée de la photo-diode est tres tres rapide). On a ainsi le temps de départ du trigger, et le temps réel d'affichage du carré. Et la, je suis perplexe. En synchro verticale avec l'écran à 85Hz, j'obtiens entre 16 et 30 millisecondes de délai (tout en affichant 85 images par secondes, sans en louper une seule, bien synchro avec l'écran, mesuré par FRAPS) donc au moins une image de décalage (11.7 ms pour un balayage complet de l'écran) voire deux selon les cas. Et sans vertical retrace actif, un délai entre 5 et 19 millisecondes.
En bref, je n'arrive pas a comprendre comment j'arrive à perdre autant de temps en synchro verticale, et comment même arriver à 19ms sans synchro.
OpenGL fonctionne en architecture client-serveur, donc je veux bien comprendre que les exécutions des différentes commandes ont un certain délai, mais meme en utilisant glFlush, et meme carrément glFinish, rien ne change.
Je trouve ces délais tres importants et n'arrive pas a les expliquer.
DirectX serait-il plus adapté à ce que je veux ?
GLUT poserait-il problème à un quelconque moment ?
J'ai même essayé de me passer du GlutSwapBuffers en me mettant en simple buffer (et non double), et donc sans synchro verticale et j'obtiens toujours un délai compris entre 6 et 19 ms.
Peut etre est-ce Windows alors ?

Ma config et mes libs, pour récapituler :
P4 3.6Ghz
Geforce2 MX 400
WinXP service pack2
Opengl
GLUT
fmod
glf
et d'autres trucs ...

Compilé en mode console, multithreaded DLL avec Visual C++ 7
Le soft est mis en mode High Priority

Voila, si quelqu'un a déjà eu l'idée de faire de telles mesures (je sais mon cas est tres particulier et en principe tout le monde s'en fout dans les jeux ou des softs de CAO ou autres) ou et en mesure de m'explquer si cela est normal, faites moi signe.
encore une fois le soft tourne tres vite, et en mode non vertical retrace, j'obtiens 140 ou plus images par secondes mais la n'est pas le pb, le pb est que les images affichées sont décalées dans le temps d'un ou deux balayages, ce qui est trop important pour moi, et que je ne comprends pas.

Bonne fin de week end