OpenGL

156 views
Skip to first unread message

sturlamolden

unread,
Oct 30, 2009, 9:58:21 AM10/30/09
to cython-users
Are you interested in a OpenGL definition file for Cython (e.g. for
the wiki)? I have a pxd/pxi for Cython and Pyrex mostly autogenerated
from parsing the header files that came with gcc. It has all of gl.h
from Mesa 4.0, glu.h and glext.h from SGI. The license for all the
source files are MIT (X11). Writing OpenGL defintions for Cython
programs is tedious and boring, so it is better to have this done once
and for all.

I have an opengl.pxi with the whole API declared, and an empty
opengl.pxd that just includes this. As we cannot "from opengl comport
*", OpenGL code looks strange with a cimport, so it is better to just
directly include a pxi.

Personally I use this with wx.glcanvas.GLCanvas from wxPython, which
gives me 3D graphics at the speed of C, while keeping the rest in
Python. When we need to call OpenGL API routines like glVertex*
thousands of times, PyOpenGL is only fit for prototyping.

P.S. I prefer to keep glut in a separate file, as glut.h are not
ubiquituous, and I don't care much about glut because I don't use it.
The glut header is small anyway, compared to the rest.



Sturla

Dag Sverre Seljebotn

unread,
Oct 30, 2009, 10:11:40 AM10/30/09
to cython...@googlegroups.com
Sturla Molden wrote:
>
> Are you interested in a OpenGL definition file for Cython (e.g. for
> the wiki)? I have a pxd/pxi for Cython and Pyrex mostly autogenerated
> from parsing the header files that came with gcc. It has all of gl.h
> from Mesa 4.0, glu.h and glext.h from SGI. The license for all the
> source files are MIT (X11). Writing OpenGL defintions for Cython
> programs is tedious and boring, so it is better to have this done once
> and for all.

We encourage contributing pxds for widespread libraries to the Cython
distribution (in the Cython/Includes folder, available in the default
Cython search path). OpenGL pxds would certainly be accepted; just provide
the files.

>
> I have an opengl.pxi with the whole API declared, and an empty
> opengl.pxd that just includes this. As we cannot "from opengl comport
> *", OpenGL code looks strange with a cimport, so it is better to just
> directly include a pxi.

I think this is no longer true in Cython, you can do "from opengl cimport
*" in 0.11.x at least.

Dag Sverre

Lisandro Dalcin

unread,
Oct 30, 2009, 10:18:19 AM10/30/09
to cython...@googlegroups.com
On Fri, Oct 30, 2009 at 12:11 PM, Dag Sverre Seljebotn
<da...@student.matnat.uio.no> wrote:
>
> Sturla Molden wrote:
>>
>> Are you interested in a OpenGL definition file for Cython (e.g. for
>> the wiki)? I have a pxd/pxi for Cython and Pyrex mostly autogenerated
>> from parsing the header files that came with gcc. It has all of gl.h
>> from Mesa 4.0, glu.h and glext.h from SGI. The license for all the
>> source files are MIT (X11).  Writing OpenGL defintions for Cython
>> programs is tedious and boring, so it is better to have this done once
>> and for all.
>

Perhaps it would be a good idea to have the stuff in gl.h, glu.h, etc
live in separate files gl.pxd, glu.pxd ... and have a opengl.pxd taht
cimport * them all ?

>
> We encourage contributing pxds for widespread libraries to the Cython
> distribution (in the Cython/Includes folder, available in the default
> Cython search path). OpenGL pxds would certainly be accepted; just provide
> the files.
>

Of course.


>>
>> I have an opengl.pxi with the whole API declared, and an empty
>> opengl.pxd that just includes this. As we cannot "from opengl comport
>> *", OpenGL code looks strange with a cimport, so it is better to just
>> directly include a pxi.
>
> I think this is no longer true in Cython, you can do "from opengl cimport
> *" in 0.11.x at least.
>

Definitely yes, try to cythonize the two lines below.

from stdlib cimport *
free(malloc(1024))


> Dag Sverre
>
>

--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

Stefan Behnel

unread,
Oct 30, 2009, 10:30:33 AM10/30/09
to cython...@googlegroups.com

Lisandro Dalcin, 30.10.2009 15:18:

> On Fri, Oct 30, 2009 at 12:11 PM, Dag Sverre Seljebotn
> <da...@student.matnat.uio.no> wrote:
>> Sturla Molden wrote:
>>> Are you interested in a OpenGL definition file for Cython (e.g. for
>>> the wiki)? I have a pxd/pxi for Cython and Pyrex mostly autogenerated
>>> from parsing the header files that came with gcc. It has all of gl.h
>>> from Mesa 4.0, glu.h and glext.h from SGI. The license for all the
>>> source files are MIT (X11). Writing OpenGL defintions for Cython
>>> programs is tedious and boring, so it is better to have this done once
>>> and for all.
>
> Perhaps it would be a good idea to have the stuff in gl.h, glu.h, etc
> live in separate files gl.pxd, glu.pxd ... and have a opengl.pxd taht
> cimport * them all ?

+1, we also do that for "python.pxd" and its API subsets in
Cython/Includes/python_*.pxd.

Stefan

sturlamolden

unread,
Oct 30, 2009, 11:34:20 AM10/30/09
to cython-users
On 30 Okt, 15:18, Lisandro Dalcin <dalc...@gmail.com> wrote:

> Perhaps it would be a good idea to have the stuff in gl.h, glu.h, etc
> live in separate files gl.pxd, glu.pxd ... and have a opengl.pxd that
> cimport * them all ?

It got too messy. There are duplicate declarations in these files,
with preprocessor magic. A defintion for Windows might be in glext.h
and a similar for Unix might be in gl.h. I could thus have uses IF/
ELIF/ELSE and DEF for conditional compilation, similar to what the
OpenGL headers do. But then it would be necceassary to tell Cython
which compiler and platform to generate code for, in order for the
conditional compilation to work. That would probably break build
scripts. And in order for Cython code to be cross-platform, one would
have to include all of them anyway. There is the KISS principle ("keep
it simple stupid"). Cython/Pyrex don't need this preprocessor magic.
It is there for the C compiler. My script makes sure everything is
defined, but only once, and in correct order for dependencies to work.
Then the C compiler can look in the OpenGL headers and see what is
really there.

So it starts like this:


cdef extern from "stddef.h":
ctypedef char wchar_t

cdef extern from "GL/gl.h":
pass

cdef extern from "GL/glu.h":
pass

cdef extern from "GL/glext.h":
pass

cdef extern from *:
unsigned int GL_VERSION_1_1
unsigned int GL_ARB_imaging
ctypedef unsigned int GLenum
ctypedef unsigned char GLboolean
ctypedef unsigned int GLbitfield
ctypedef void GLvoid
ctypedef char GLbyte
ctypedef short GLshort
ctypedef int GLint
ctypedef unsigned char GLubyte
ctypedef unsigned short GLushort
ctypedef unsigned int GLuint
ctypedef int GLsizei
ctypedef float GLfloat
ctypedef float GLclampf
ctypedef double GLdouble
ctypedef double GLclampd
unsigned int GL_FALSE
unsigned int GL_TRUE
unsigned int GL_BYTE



> Definitely yes, try to cythonize the two lines below.
>
> from stdlib cimport *
> free(malloc(1024))

Yes you are right, I got a bit confused there. (It was actually due to
my license statement not making the pxd decodable with UTF-8).


Sturla


sturlamolden

unread,
Oct 30, 2009, 12:56:39 PM10/30/09
to cython-users


On 30 Okt, 16:34, sturlamolden <sturlamol...@yahoo.no> wrote:

> It got too messy. There are duplicate declarations in these files,
> with preprocessor magic. A defintion for Windows might be in glext.h
> and a similar for Unix might be in gl.h.

Hm... maybe the cimport mechanism would deal with namespace
collisions? In Python you just get the name bound to something else.


Sturla

Lisandro Dalcin

unread,
Oct 30, 2009, 1:14:13 PM10/30/09
to cython...@googlegroups.com

Well, the defenders of Python's semantics would say no... But I would
still like to have a way (not on by default) to ask Cython to at least
generate a warnings (but only if the collision have different
types/signatures) ...

Dag Sverre Seljebotn

unread,
Oct 30, 2009, 2:17:37 PM10/30/09
to cython...@googlegroups.com

On that note, I think it would be better to have an hierarchy. Using
Python as an example, I'd rather have

cimport cpython.exc
cimport cpython.buffer

and so on. (I don't think we should change the way it is for CPython now,
but something to keep in mind for new additions.)

Dag Sverre

Reply all
Reply to author
Forward
0 new messages