Re: [PyOpenGL-Devel] Thoughts about PyOpenGL, and other stuff.

[matthew s. <mat...@gm...>]

So here a year later i thought I would give you an update on this. I really
only started working on this again about a month ago, but i've made decent
progress since.

Still a lot of stuff to do, but i've made decent progress at reading the
xml registry(only really need to do extensions now), and generating a
binding.
Didn't end up using your code though plus i've never been a fan of
ElementTree fan. So I ended up making a wrapper around xml.parser.expat to
do the parsing of the xml registry.

I still have a lot of ideas and plans for this, mainly:
- Wrapper layer that is mostly compatible with pyopengl.
- Basic context creation code for various platforms (no late binding for gl
calls)
- Various run-time, and generation-time options to customize the binding
depending on the needs of a project.

The code is here: https://github.com/mdsitton/pyogl

If you have any feedback I would be glad to hear it.

Thanks, Matthew

On Thu, Oct 2, 2014 at 10:41 PM, Mike C. Fletcher <mcf...@vr...>
wrote:

> 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
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>