Re: [PyOpenGL-Devel] Thoughts about PyOpenGL, and other stuff.
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@vr...> - 2014-10-03 03:41:21
|
On 02/10/14 16:15, matthew sitton wrote: > So i have been thinking about starting my own opengl binding for > python, but i thought why not come here and post some of what i am > wanting out of an opengl binding. Sounds fun, be aware that there are actually a *lot* of Python OpenGL bindings, so you might want to survey them first to see if there is a jump-start available. > Make "Modern OpenGL" a first class citizen. Mainly this would involve > the following in my opinion: > - Provide a math library (Something generally equivalent to GLM or others) Math libraries are a hard one IMO. GLM is something like 20,000 lines of code, Numpy is huge (quarter of a million LOC or so). A wrapper around GLM would be great, something sip-based (or the like) that would let you use GLM vectors etc naturally from Python would be cool. Thing is, that really sounds like a separate project (both in terms of scope and focus) from PyOpenGL. Similarly, while I have a library of code for using Numpy in my scenegraph it doesn't seem like something that should be dropped into PyOpenGL. Basic problem in my mind is that any sufficiently useful/clean/attractive math library likely should be its own project, potentially with support in PyOpenGL for it (e.g. as Numpy is directly supported). > - Support opengl profiles, core forward compatible, and compatibility > based off of the xml registry. Sure, using the Registry is pretty much a given, I would think. I'm not sure whether you'll see a huge advantage to the core vs. compatibility profiles, I suppose memory usage and start-up might be better. > - This would also mean providing imports for opengl functionality > levels, so if you import OpenGL 3.3 core, you would be returned a > module that contains all of the required Features at that > functionality level, and none of the removed features. Should be pretty straightforward to do that. The registry has all of the information for generating those namespaces. However, currently the manually-wrapped code is all tied into the current module-per-extension structure. > I also think it would be interesting to experiment with reorganization > of the code to provide an abstraction of ctypes so that a cffi backend > could be introduced. This should allow PyOpenGL to run under pypy with > improved performance. I believe there's actually a fork of PyOpenGL somewhere that did a ctypes -> cffi translation. I don't know if there was any performance improvements. I wouldn't get my hopes up *too* much as a *lot* of the overhead in PyOpenGL is due to munging the parameters to functions to make APIs "pythonic", that overhead is significantly reduced by the OpenGL_accelerate module, which likely won't be useful under PyPy. Something like Pyglet, which uses the C api directly should give you a much better bang-for-the-buck improvement in a cffi translation (IIRC they may have already done that translation too). > I have also been thinking about digging into the source, and figuring > out how the whole thing works better. That way i could contribute to > the project. I read through this document: > http://pyopengl.sourceforge.net/documentation/development.html > However i suspect that its outdated. Yup, it's definitely outdated, the whole raw-wrapper hierarchy is now generated from the XML registry. You can start reading at `src/xml_generate.py` which is the overall runner that regenerates the automated wrappers. In particular, if you want to generate your own wrappers you'll likely want to look at `src/xmlreg.py` which takes the xml and generates an in-memory model of the APIs. The module `src/codegenerator.py` is the stuff that actually spits out the modules and packages. You should pretty easily be able to modify that to spit out a different style of wrapper. I'd say just go ahead and play with generating a wrapper in a form you feel is good. PyOpenGL tries to be newbie-friendly and does a *lot* of stuff that really shouldn't be done if you are concerned about creating a fast engine. Really, if you want to build a fast engine you likely don't care much about the API you are using, so using a raw wrapper (i.e. direct cffi or Cython access to unvarnished C-style API) is likely what you want; you're going to build abstractions over it anyway, so you don't need them at the API level; pyglet is the obvious example of how to make that work. Things I'd suggest doing if you want a simple, clean, fast API: * no lists/tuples/incorrect-formats; demand a binary-compatible, buffer-protocol-supporting (or native cffi/ctypes) data-type for all pointer/array parameters * no pointer management; just let the user crash if they forget to keep the object pointer around, maybe provide a debug mode that uses weakref-based logging to display which objects are being deallocated to make it easier to debug crashes * don't muck about with the low-level API unnecessarily, every time you imply parameters or unpack values to be "friendly" you increase the overhead * drop GLX, GLU, GLUT, WGL * don't provide context-checking or the like to try to catch errors, just let the crashes happen * use a gl-object with attribute lookup instead of actual modules, so you only need to load those entry points that get used (note, you'll get error reports that this makes IDEs unable to find names, sorry about that) I believe you'll find that's *basically* pyglet's automated wrappers, or SWIG's automated wrappers. I think there's even a Cython wrapper that basically follows this approach. Anyway, go for it. I'm happy to give you assistance on how to use the PyOpenGL/src tools to generate your own wrapper, and if something is obviously better I'm happy to look at adopting it for PyOpenGL. If you want to do something like adding a function to the OpenGL root namespace (something like) get_feature('GL_VERSION_1_1',profile='core') just to get started playing, that would be fine too. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |