Thread: [PyOpenGL-Users] OPENGL
Brought to you by:
mcfletch
From: Jason W. <ir...@gm...> - 2007-03-10 21:38:16
|
Python is extensible with C++. So why not just take the gl.h glu.h and friends and mod them so python can call them? wouldn't this be faster than your wrapper around ctypes? |
From: JoN <jo...@we...> - 2007-03-13 01:10:30
|
Quoting Jason Ward <ir...@gm...>: > Python is extensible with C++. > So why not just take the gl.h glu.h and friends > and mod them so python can call them? Isn't that exactly what PyOpenGL does? > wouldn't this be faster than your wrapper around ctypes? > Its hard to imagine anything faster than ctypes, as it binds calls directly to the binary code in the .so/.dll's -------------------------------------------------------------------- Come and visit Web Prophets Website at http://www.webprophets.net.au |
From: Mike C. F. <mcf...@vr...> - 2007-03-13 04:19:47
|
JoN wrote: > Quoting Jason Ward <ir...@gm...>: > > >> Python is extensible with C++. >> So why not just take the gl.h glu.h and friends >> and mod them so python can call them? >> > > Isn't that exactly what PyOpenGL does? > It's sort-of what PyOpenGL does. I believe Jason was asking why we don't use C directly to gain speed. The answer is basically that the maintenance headaches outweigh the performance gain (to the extent that the system would likely have been abandoned if we'd kept on with the hand-coded, and then SWIG-coded wrappers). >> wouldn't this be faster than your wrapper around ctypes? >> > > Its hard to imagine anything faster than ctypes, as it binds calls directly to > the binary code in the .so/.dll's > Actually, ctypes is quite slow compared to e.g. SWIG. That's because it does a lot more work at run-time for every call than a SWIG or similar system does. OpenGL-ctypes (PyOpenGL) is even slower because it has to provide the array and similar semantics that aren't available in ctypes' core. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Greg E. <gre...@ca...> - 2007-03-13 12:47:37
|
Mike C. Fletcher wrote: > The answer is basically that the > maintenance headaches outweigh the performance gain (to the extent that > the system would likely have been abandoned if we'd kept on with the > hand-coded, and then SWIG-coded wrappers). Have you considered using Pyrex? > Actually, ctypes is quite slow compared to e.g. SWIG. That's because it > does a lot more work at run-time for every call than a SWIG or similar > system does. OpenGL-ctypes (PyOpenGL) is even slower because it has to > provide the array and similar semantics that aren't available in ctypes' > core. This is a little worrying, as OpenGL calls are something you really don't want being inefficient. I'm hoping this is more of a theoretical than practical concern. Has anyone done any measurements? -- Greg |
From: horace <hor...@gm...> - 2007-03-16 04:40:54
|
would it be possible to write a tool which automatically converts ctype wrappers to pyrex? wouldn't that be nice? i am no computer scientist though and maybe this is a stupid idea which isn't feasible. :) On 3/15/07, Thomas Heller <th...@ct...> wrote: > > Greg Ewing schrieb: > > Mike C. Fletcher wrote: > >> Actually, ctypes is quite slow compared to e.g. SWIG. That's because > it > >> does a lot more work at run-time for every call than a SWIG or similar > >> system does. OpenGL-ctypes (PyOpenGL) is even slower because it has to > >> provide the array and similar semantics that aren't available in > ctypes' > >> core. > > > > This is a little worrying, as OpenGL calls are something you > > really don't want being inefficient. I'm hoping this is more > > of a theoretical than practical concern. Has anyone done any > > measurements? > > Andrew Dalke as written two nice articles about ctypes that I know of: > > http://www.dalkescientific.com/writings/NBN/ctypes.html > http://www.dalkescientific.com/writings/NBN/c_extensions.html > > The latter has some comparisons between ctypes and a C-coded > extension. > > Thomas > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: JoN <jo...@we...> - 2007-11-09 04:14:26
|
Quoting "Mike C. Fletcher" <mcf...@vr...>: > Actually, ctypes is quite slow compared to e.g. SWIG. That's because it > does a lot more work at run-time for every call than a SWIG or similar > system does. OpenGL-ctypes (PyOpenGL) is even slower because it has to > provide the array and similar semantics that aren't available in ctypes' > core. > Good gods, is this still the case? Jon > Have fun, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -------------------------------------------------------------------- Come and visit Web Prophets Website at http://www.webprophets.net.au |
From: Thomas H. <th...@ct...> - 2007-03-15 09:21:51
|
Greg Ewing schrieb: > Mike C. Fletcher wrote: >> Actually, ctypes is quite slow compared to e.g. SWIG. That's because it >> does a lot more work at run-time for every call than a SWIG or similar >> system does. OpenGL-ctypes (PyOpenGL) is even slower because it has to >> provide the array and similar semantics that aren't available in ctypes' >> core. > > This is a little worrying, as OpenGL calls are something you > really don't want being inefficient. I'm hoping this is more > of a theoretical than practical concern. Has anyone done any > measurements? Andrew Dalke as written two nice articles about ctypes that I know of: http://www.dalkescientific.com/writings/NBN/ctypes.html http://www.dalkescientific.com/writings/NBN/c_extensions.html The latter has some comparisons between ctypes and a C-coded extension. Thomas |
From: Mike C. F. <mcf...@vr...> - 2007-03-16 20:47:03
|
horace wrote: > would it be possible to write a tool which automatically converts > ctype wrappers to pyrex? wouldn't that be nice? > > i am no computer scientist though and maybe this is a stupid idea > which isn't feasible. :) In fact, PyPy is able to translate a subset of ctypes into a number of code types including C code with type inferencing allowing for significant code simplification... i.e. the code should get close to the speed of directly C-coded source code. The wrappers are also built from gcc-xml output (for the "raw" API), I *believe* pyrex already has a mechanism that allows for the same transformation (i.e. build a raw API from raw gcc-xml). Which is to say, we could, in theory, provide a way to register a "raw" API plugin for PyOpenGL that would allow for entirely replacing the core-code operations (or something like that). That way a compiled system could provide a run-time pluggable replacement for the pure-python code... in theory, anyway... Have to get back to work now. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: horace <hor...@gm...> - 2007-03-17 07:37:04
|
so if i understand this correctly, pyopengl consist of an auto-generated "raw" opengl layer and another layer on top of it which makes it more "pythonic"? and the auto-generated ctypes "raw" layer could in theory be replaced with an auto-generated pyrex "raw" layer? and this could make pyopengl a bit faster? :) sounds interesting... i also find the pypy project very fascinating. i am looking forward to see the first parts of it getting production ready and also to see how fast they can get python with their jit work. On 3/16/07, Mike C. Fletcher <mcf...@vr...> wrote: > > horace wrote: > > would it be possible to write a tool which automatically converts > > ctype wrappers to pyrex? wouldn't that be nice? > > > > i am no computer scientist though and maybe this is a stupid idea > > which isn't feasible. :) > In fact, PyPy is able to translate a subset of ctypes into a number of > code types including C code with type inferencing allowing for > significant code simplification... i.e. the code should get close to the > speed of directly C-coded source code. > > The wrappers are also built from gcc-xml output (for the "raw" API), I > *believe* pyrex already has a mechanism that allows for the same > transformation (i.e. build a raw API from raw gcc-xml). Which is to > say, we could, in theory, provide a way to register a "raw" API plugin > for PyOpenGL that would allow for entirely replacing the core-code > operations (or something like that). That way a compiled system could > provide a run-time pluggable replacement for the pure-python code... in > theory, anyway... > > Have to get back to work now. > > Have fun, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: Greg E. <gre...@ca...> - 2007-03-18 00:07:07
|
horace wrote: > so if i understand this correctly, pyopengl consist of an auto-generated > "raw" opengl layer and another layer on top of it which makes it more > "pythonic"? and the auto-generated ctypes "raw" layer could in theory be > replaced with an auto-generated pyrex "raw" layer? If the ctypes layer is already being auto-generated, there shouldn't be any technical obstacle to generating Pyrex definitions instead, I would think. -- Greg |