Etrange problème DisplayList

J'ai un problème avec l'option GL_COMPILE et GL_COMPILE_AND_EXECUTE pour la fonction glNewList.

Dans mon gigantesque programme, quand j'appelle glNewList avec GL_COMPILE_AND_EXECUTE, l'appel est légèrement plus long, sans problèmes.

Maintenant, si j'appelle avec GL_COMPILE, je gagne un temps négligeable a l'appel newlist mais je perds un temps considérable plus tard dans l'initialisation mais qui ne se repère pas plus que ca après pendant l'affichage des DL.

Quelqu'un est familier avec ce comportement pour le moins étrange ?

Bonjour,

De mémoire cela dépend de ce que vous essayez de mettre dans la liste d'affichage.
Car si l'affichage ( calcul des commandes graphiques ) est rapide, le GL_COMPILE_AND_EXECUTE ne va pas faire gagner beaucoup de temps. ( À part dans un très très grand nombre de rendu de la liste )
Donc j'imagine que cela est votre cas ( affichage rapide ).

Après je suis un peu perdu pour l'initialisation, mais je sais que les listes d'affichage prennent beaucoup de mémoire vive ( RAM )

Je vais faire quelques précisions maintenant que j'ai pu debugger en profondeur.

La displaylist en question contient un bete ( TRES BETE ) assemblage de triangles et de normales (7000~) rien d'exotique une affectation de matériel et rien d'autre.

Donc j'initialise avec GL_COMPILE_AND_EXECUTE tout se passe "bien", l'initialisation prend ~2, 3 secondes.

Si je met GL_COMPILE maintenant, toute l'initialisation prends pareil, 2, 3 secondes mais, le premier appel de ma displaylist prend 5 secondes (!) comme si on appelait pas une DL en fait ... et les appels suivants 0 secondes :|

Je suis sidéré.

quand on a des préoccupations au niveau des performances comme c'est ton cas, le plus logique est d'utiliser les VBO

les raisons qui peuvent pousser à utiliser les DL sont plutôt la simplicité d'utilisation

Si je pouvais utiliser autre chose que les DL tu penses bien que je le ferais, c'est pas a moins qu'incombe la décision.

Et la n'est pas la question ...

En tout cas j'ai optimisé la DL elle meme et maintenant j'ai zéro attente a la création et a l'exécution. Cependant, j'ai un léger problème de conscience.

Quand je compile avec GL_COMPILE, j'obtiens un léger lag a l'initialisation ( je clique, il se passe un pouillième de temps et ca fonctionne )
Mais quand j'utilise GL_COMPILE_AND_EXECUTE, j'ai zéro zéro attente. Par contre et je suis encore une fois abasourdis du résultat .. l'affichage est moins rapide :|

je dois avoir quelque chose comme 40 FPS avec GL_COMPILE et 20 FPS avec GL_COMPILE_AND_EXECUTE ...

personne n'a étudié le probleme ?

Bonjour,

je n'ai pas de réponse précise à vous donner, mais:

Citation:

---

Quand je compile avec GL_COMPILE, j'obtiens un léger lag a l'initialisation ( je clique, il se passe un pouillième de temps et ca fonctionne )
Mais quand j'utilise GL_COMPILE_AND_EXECUTE, j'ai zéro zéro attente

---

Ca ca me parait logique: COMPILE_AND_EXECUTE compile la liste ET affiche en même temps, alors qu'avec GL_COMPILE il faut appeler la liste explicitement (et donc la charger en memoire) avant de pouvoir l'afficher, d'où cette petite attente.

Après, je suis d'accord que la différence de 20 FPS selon quel type de liste est chargé, c'est bizarre....Êtes-vous sûr que c'est la seule différence?

Au pire, ce n'est pas une solution mais pourquoi ne pas garder GL_COMPILE_AND_EXECUTE comme ca à défaut de comprendre pourquoi?

Dans les conditions actuelles, à l'affichage c'est GL_COMPILE le plus rapide donc je le garde. ( je répète, GL_C > initialisation lente, affichage rapide et GL_C&E > initialisation rapide, affichage lent - et pas le contraire )

Je me posais juste la question. Avant c'etait handicapant, maintenant ca ne l'est plus vraiment, je peux me contenter de ce que j'ai.

Mais je me pose la question, c'est le développeur curieux qui parle là.