Thread: [PyOpenGL-Devel] Significant restructuring of the 3.x codebase
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@vr...> - 2006-11-12 21:22:46
|
I've just checked in a fairly significant restructuring of the 3.x (OpenGL-ctypes) codebase. What this does is to use the latest ctypes auto-generator (actually a fairly heavily refactored version of it) to produce a separate package hierarchy (OpenGL.raw) which contains the raw OpenGL C-style API. This API can be used by ctypes-aware code that uses C-style interfaces, it also allows for coding around problems where the PyOpenGL abstraction layer happens to get in the way. One thing to note is that all of the constants and functions are now produced by the auto-generator, this means that there is sometimes more machinery in the module than you would expect (e.g. the GLX module now has large parts of the X API). At the moment I'm thinking (in the case of GLX) much of that machinery is actually useful (if somewhat misplaced). e.g. the functions for screen saver development are likely in there now. Probably filter them out at some point I suppose. I've done some preliminary testing. On Linux AMD64 the OpenGLContext tests all run as well as they did before the restructuring. I'm going to boot into Win32 to try to get the GLUT hang-on-exit bug fixed and that will probably be it for work on OpenGL-ctypes this week. Testing elsewhere with the new structure would be helpful. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mark H. <ma...@mi...> - 2006-11-13 20:35:10
|
Mike C. Fletcher wrote: > I've just checked in a fairly significant restructuring of the 3.x > (OpenGL-ctypes) codebase. What this does is to use the latest ctypes > auto-generator (actually a fairly heavily refactored version of it) to > produce a separate package hierarchy (OpenGL.raw) which contains the raw > OpenGL C-style API. This API can be used by ctypes-aware code that uses > C-style interfaces, it also allows for coding around problems where the > PyOpenGL abstraction layer happens to get in the way. > > One thing to note is that all of the constants and functions are now > produced by the auto-generator, this means that there is sometimes more > machinery in the module than you would expect (e.g. the GLX module now > has large parts of the X API). At the moment I'm thinking (in the case > of GLX) much of that machinery is actually useful (if somewhat > misplaced). e.g. the functions for screen saver development are likely > in there now. Probably filter them out at some point I suppose. > It strikes me that a 'raw' API release like this, followed lease by or released concurrently with a more sophisticated Pythonic API, is the model to follow for most Python ports of mature C/C++ projects. It lowers the transition bar for both the existing user base and the Py port developer since a) the C/C++ users don't have to learn a new API on top the required Python newness, b) the documentation is essentially already in place*, c) the autogen nature of the raw port makes it easier to maintain absent the full concentration of the primary Py developer, and finally d) as consequence of a,b,&c the bug reports are likely to be more valid/correct. The Pygame ctypes port, with all its good work, is illustrative of the problems caused by skipping the raw API (e.g. threatened forks etc.) * this BTW makes it straightforward to auto include the documentation as Py doc strings in the raw module. Mark |
From: Mike C. F. <mcf...@vr...> - 2006-11-14 04:19:08
|
Mark Heslep wrote: > Mike C. Fletcher wrote: > >> I've just checked in a fairly significant restructuring of the 3.x >> (OpenGL-ctypes) codebase. What this does is to use the latest ctypes >> auto-generator (actually a fairly heavily refactored version of it) to >> produce a separate package hierarchy (OpenGL.raw) which contains the raw >> OpenGL C-style API. This API can be used by ctypes-aware code that uses >> C-style interfaces, it also allows for coding around problems where the >> PyOpenGL abstraction layer happens to get in the way. >> >> One thing to note is that all of the constants and functions are now >> produced by the auto-generator, this means that there is sometimes more >> machinery in the module than you would expect (e.g. the GLX module now >> has large parts of the X API). At the moment I'm thinking (in the case >> of GLX) much of that machinery is actually useful (if somewhat >> misplaced). e.g. the functions for screen saver development are likely >> in there now. Probably filter them out at some point I suppose. >> >> > It strikes me that a 'raw' API release like this, followed lease by or > released concurrently with a more sophisticated Pythonic API, is the > model to follow for most Python ports of mature C/C++ projects. I was apparently unclear. By "separate package hierarchy" I meant a sub-package of OpenGL whose structure mirrors that of the main package hierarchy. That is, it will all be distributed together for the OpenGL package. What may happen is either that Pyglet uses the auto-generator to create their own copy of the hierarchy (in pyglet.GL). The other option is to make the OpenGL package a setuptools namespace package, though I'm not sure that would work particularly well with the modules right at the OpenGL.* level. > It > lowers the transition bar for both the existing user base and the Py > port developer since a) the C/C++ users don't have to learn a new API on > top the required Python newness, b) the documentation is essentially > already in place*, c) the autogen nature of the raw port makes it easier > to maintain absent the full concentration of the primary Py developer, > and finally d) as consequence of a,b,&c the bug reports are likely to be > more valid/correct. The Pygame ctypes port, with all its good work, is > illustrative of the problems caused by skipping the raw API (e.g. > threatened forks etc.) > Hadn't heard anything about that. I actually see the "raw" API as something of a specialist's feature. It doesn't really make a particularly useful API to have to code every little C idiom in Python, so you have to have a special reason for doing it, such as needing to get around a Python abstraction layer problem. Anyway, if it makes it easier for a C coder or the Pyglet guys, yay :) . Even if it doesn't, it makes for a more consistent layout for the package and gives easy access to the raw API for advanced coders, so we'll likely go this way. > * this BTW makes it straightforward to auto include the documentation as > Py doc strings in the raw module. > There's already basic documentation in the raw module. The thing to keep in mind is that PyOpenGL's online documentation is based on the XML docbook source for OpenGL, GLUT and GLE, and the resulting generated files are *big* (about 8.9MB) and not particularly pydoc-friendly, not really something you want to include in the source-code. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |