Re: Thoughts about PyOpenGL, and other stuff.

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


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net