Discussion :

[ShevchenKik]

Bonjour,

j'utilise depuis quelques temps la tesselation pour effectuer le rendu de polygônes convexes. Ca marche très bien...jusqu'à ce que je me rende compte que la combine Callback cause des memory leak...

Voici le code de ma callback:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void CALLBACK combineCallback(GLdouble coords[3], GLdouble *vertex_data[4],
							  GLfloat weight[4], GLdouble **dataOut)
{
	GLdouble *vertex;
 
	vertex = (GLdouble *) malloc(3 * sizeof(GLdouble));
	vertex[0] = coords[0];
	vertex[1] = coords[1];
	vertex[2] = coords[2];
 
	*dataOut = vertex;
}

C'est calqué sur le code du red book (en plus simple car je n'ai pas besoin d'interpoler les couleurs ou les normales...) donc a priori...

Bon, ce que fait la callback: elle alloue de la memoire pour un vertex et l'envoit en sortie... je m'attendrai donc a ce qu'OpenGL (ou GLU dans ce cas) libere la memoire de lui-même apres utilisation du vertex, mais non...

J'ai trouvé cet exemple: http://www.codeguru.com/cpp/g-m/open...icle.php/c9137

où la combine callback est implémentée comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CPtrList CMFCTessView::gm_VertexPtrList ; //static memvar used to keep track of newly allocated vertices
void CALLBACK CMFCTessView::combineCallback(GLdouble coords[3], 
                     GLdouble *vertex_data[4],
                     GLfloat weight[4], GLdouble **dataOut )
{
	GLdouble *vertex = new GLdouble[6] ;
	gm_VertexPtrList.AddTail( vertex ) ; //keep track for later delete[] at bottom of CMFCTessView::OnDraw() 
 
	vertex[0] = coords[0];
	vertex[1] = coords[1];
	vertex[2] = coords[2];
	vertex[3] = vertex[4] = vertex[5] = 0. ; //01/13/05 bugfix
 
	*dataOut = vertex;
}

Là on garde une trace de la mémoire allouée pour pouvoir la libérer après le dessin.

Ca peut bien entendu résoudre mon problème mais:
- Est-ce normal?
- Si oui, comment une telle erreur de conception peut rester encore présente des années après la sortie de GLU 1.2???
- Et toujours si oui, pourquoi n'est ce documenté nul part, et en particulier pas dans le red book?

=> ce qui me fait penser que non, ca n'est pas normal, mais en meme temps comme je trouve des exemples comme celui ci-dessus....

Bref, j'attends avec impatience vos avis sur ce truc à priori abherrant...

[LittleWhite]

Bonjour,

Je ne vois pas cela comme une chose aberrante.

Le callback est appelé en allouant de la mémoire, certes. Mais comme c'est de la mémoire que l'on va utiliser plus tard ( hors du callback ) alors on va pas désallouer dans le callback ( ce qui reste normal ).

Dans la première methode ( celle du livre ) tu garde toujours une trace de ta mémoire avec le dataOut.
C'est sur celui ci que tu fera un free pour désallouer la mémoire allouer par le callback.

La deuxième méthode fais la même chose, sauf qu'elle garde une trace dans une queues. ( et aussi qu'elle en C++ )

Enfin le callback est appelée à quel moment ?

[ShevchenKik]

Bonjour,

oui ok ce n'est peut-être pas si aberrant que ca.... c clair que sur le principe, on cree un nouveau vertex (la combine callback est appellée lors de la tesselation quand un nouveau sommet est requis) donc qq part il faut allouer.

Ce qui me chiffonne c'est que dans le Red book et la majorité des exemples que j'ai trouvé sur le net, il n'y a aucune mention de ce "détail". Quand j'implémente, à la lettre, un exemple de code d'un bouquin (qui en est a sa 6eme édition, quand même...), je m'attends à ce que ca fonctionne et sans fuites de mémoires et cie...

bref, j'ai utilisé la méthode décrite dans mon 1er post pour garder une trace des sommets alloués et les libérer plus tard. Ca marche sans problème... Disons qu'il faudrait juste mettre l'exemple du red book a jour...

(je mets la discussion comme "résolue", même si le probleme de fond ne l'est pas)