issue 2
(Tesselator leaks memory) reported by qtvali
- I have some iPhone test code doing tesselation (ported some example).
static void combineCallback(GLdouble coords[3], GLdouble *vertex_data[4],
GLfloat weight[4], GLdouble **dataOut)
This method will create some array - vertex = (GLdouble *) malloc(6 * sizeof(GLdouble)); -, which
will be sent to static void vertexCallback(GLvoid *vertex). When I build with Run->Start With
Performance Tool->Leaks, it will show several leaks.
One leak, GeneralBlock-48, happens with allocation at this method, which I pasted here. Some
other leaks are also happening.
Use extended detail view of leaks to easily detect, where those leaks are happening.
I have some iPhone test code doing tesselation (ported some example).
static void combineCallback(GLdouble coords[3], GLdouble *vertex_data[4],
GLfloat weight[4], GLdouble **dataOut)
This method will create some array - vertex = (GLdouble *) malloc(6 * sizeof(GLdouble)); -, which
will be sent to static void vertexCallback(GLvoid *vertex). When I build with Run->Start With
Performance Tool->Leaks, it will show several leaks.
One leak, GeneralBlock-48, happens with allocation at this method, which I pasted here. Some
other leaks are also happening.
Use extended detail view of leaks to easily detect, where those leaks are happening.
Jun 30, 2009
issue 1
(glu.h should not #include <OpenGLES/ES1/glext.h>) commented on by davidknott
- Note also that some of the source makes use of code which is invalid under OpenGL ES 2.0.
I believe that this is limited to the functions gluPerspective, gluLookat, and
gluOrtho2D in project.c. However, since OpenGL ES 2.0 lacks a fixed function
pipeline, these functions should in any case never be invoked within an ES 2.0 context.
Note also that some of the source makes use of code which is invalid under OpenGL ES 2.0.
I believe that this is limited to the functions gluPerspective, gluLookat, and
gluOrtho2D in project.c. However, since OpenGL ES 2.0 lacks a fixed function
pipeline, these functions should in any case never be invoked within an ES 2.0 context.
Jun 30, 2009
issue 1
(glu.h should not #include <OpenGLES/ES1/glext.h>) reported by davidknott
- It seems incorrect to #include <OpenGLES/ES1/glext.h> through glu.h
With iPhone OS 3.0, it is possible to develop applications using OpenGL ES
2.0, which requires only #include <OpenGLES/ES2/glext.h>
While one could #include both headers, doing so has two drawbacks:
1) <OpenGLES/ES2/glext.h> is not present in iPhone OS 2.X
2) When developing purely for OpenGL ES 2.0, there are many ES 1.1
functions that are invalid. If <OpenGLES/ES1/glext.h> is included, this
won't be known until runtime, whereas if it is not included, attempting to
use 1.1-only functions will result in a compile-time error (making it
easier to detect invalid code). A similar situation pertains when
developing code pure ES 1.1 code (i.e. ES 2.0 headers are unnecessary and
possibly harmful)
It seems incorrect to #include <OpenGLES/ES1/glext.h> through glu.h
With iPhone OS 3.0, it is possible to develop applications using OpenGL ES
2.0, which requires only #include <OpenGLES/ES2/glext.h>
While one could #include both headers, doing so has two drawbacks:
1) <OpenGLES/ES2/glext.h> is not present in iPhone OS 2.X
2) When developing purely for OpenGL ES 2.0, there are many ES 1.1
functions that are invalid. If <OpenGLES/ES1/glext.h> is included, this
won't be known until runtime, whereas if it is not included, attempting to
use 1.1-only functions will result in a compile-time error (making it
easier to detect invalid code). A similar situation pertains when
developing code pure ES 1.1 code (i.e. ES 2.0 headers are unnecessary and
possibly harmful)
