Yes, from what I have seen the differences are negligible (the links I found stated that) a few fps or something. And the new opengl has support for more features, the old version only goes to like opengl 1.2 compatibility or something when I last checked.
I would recommend you use the ctypes one over the old one even if doing immediate mode ;) On Tue, Mar 17, 2009 at 10:43 PM, Casey Duncan <ca...@pandora.com> wrote: > With the emphasis these days on batch operations (VBOs, etc) and doing more > and more of the work on the video card itself via shaders, I seriously doubt > that the bottleneck of a well-written, modern PyOpenGL application will be > the ctypes overhead. The only time I could see that could be would be for > immediate mode usage, which is deprecated anyhow, for the simple reason that > per-vertex operations no longer mesh well with a modern graphics > architecture. > > If you are not writing a modern OpenGL app, then by all means, use the old > version. It's going to be a while I think before cards drop support OpenGL 2 > and earlier features. It will happen eventually though. > > There are significant maintenance advantages to ctypes over C-wrappers, > generated by SWIG or otherwise. It is difficult to make the latter work well > across platforms and python versions. If you've ever looked at the build > system for PyOpenGL 2.x, you'd understand what I mean. And this is coming > from somebody who enjoys writing C extensions, but for wrapping existing > APIs, ctypes is the state of the art. Like Python itself it trades execution > speed for development efficiency and better portability. > > PyOpenGL is more or less a one man project afaik, and let me tell you, > development efficiency rules when you're trying to move mountains yourself. > > -Casey > > > On Mar 17, 2009, at 7:37 PM, Richie Ward wrote: > > why did they not make 3.0 with swig? >> >> On Tue, Mar 17, 2009 at 12:26 PM, RB[0] <roeb...@gmail.com> wrote: >> >>> http://groups.google.com/group/pyglet-users/msg/832b15389fccd28d?pli=1 >>> >>> Hmm, this is a bit outdated, but I found a few other references that say >>> SWIG will generally be faster to run, though would have more overhead - >>> so I >>> dunno. >>> >>> HTH >>> >>> On Tue, Mar 17, 2009 at 7:17 AM, RB[0] <roeb...@gmail.com> wrote: >>> >>>> >>>> I saw saw tests for performance between the old C PyOpenGL and the new >>>> ctypes one... >>>> The older one was significantly faster from what I saw - but that is how >>>> it will always be - direct usage of a C lib is just like calling C >>>> functions >>>> and such - whereas ctypes you have to call a python function (which may >>>> call >>>> others) which will execute the C lib code... >>>> >>>> I'll see if I can't find the page somewhere... >>>> >>>> On Mon, Mar 16, 2009 at 3:44 PM, Brian Fisher < >>>> br...@hamsterrepublic.com> >>>> wrote: >>>> >>>>> >>>>> That's what PyOpenGL 2.0 was - a C extension instead of ctypes. (made >>>>> with SWIG) >>>>> >>>>> I actually still use PyOpenGL 2.0 for reasons other than performance >>>>> (py2exe packaging) - I had to build it myself on windows for Python >>>>> 2.5, you >>>>> can get at an installer for it here: >>>>> http://thorbrian.com/pyopengl/builds.php >>>>> >>>>> I've never performance tested the difference between it and 3.0 though >>>>> - >>>>> is somebody else could do that, I'd love to see the results >>>>> >>>>> On Mon, Mar 16, 2009 at 10:49 AM, Zack Schilling >>>>> <zack.schill...@gmail.com> wrote: >>>>> >>>>>> >>>>>> If someone did this and I could drop it in to my code, that would be >>>>>> very nice. But for right now, PyOpenGL is serving my needs just fine. >>>>>> I can >>>>>> use about 600 independently textured and animated sprites onscreen, >>>>>> scaled >>>>>> and rotated, without stressing a low-end system more than 40%. >>>>>> >>>>>> On Mar 16, 2009, at 1:00 PM, Forrest Voight wrote: >>>>>> >>>>>> Would writing a replacement for PyOpenGL in C instead of in Python >>>>>>> with ctypes help? I think it really would ... PyOpenGL is internally >>>>>>> pretty complex, sometimes when I get tracebacks the error is 5 or 6 >>>>>>> levels into PyOpenGL. Even a C library that only implemented the >>>>>>> common functions and relied on PyOpenGL for the constants and >>>>>>> functions that do complex things like handling strings would probably >>>>>>> help a lot. >>>>>>> >>>>>>> >>>>>>>> Another way to increase speed is to write an opengl rendering engine >>>>>>>> in C and call and make it available as a Python extension. This is >>>>>>>> a major speed boost, in particular for a large number of iterations. >>>>>>>> Iirc PyOpenGL bindings are generated, many times this is suboptimal >>>>>>>> code for what you're trying to do, writing the Python extension in C >>>>>>>> manually have been faster for me many times. This is indeed true >>>>>>>> if you put your iterations inside a C loop instead of calling the >>>>>>>> C function from Python many times. >>>>>>>> >>>>>>>> >>>>> >>>> >>> >>> >> >> >> -- >> Thanks, Richie Ward >> > >
