Thread: [PyOpenGL-Users] Pyopengl same as opengl?
Brought to you by:
mcfletch
From: Tham T. H. <tha...@ho...> - 2006-06-11 14:17:29
|
is pyopengl similar to opengl in its performace? thanks for any answer. _________________________________________________________________ Download MSN Messenger emoticons and display pictures. http://ilovemessenger.msn.com/?mkt=en-sg |
From: altern <al...@gm...> - 2006-06-12 15:58:17
|
hi Tham Tham Ting Hoi escribió: > is pyopengl similar to opengl in its performace? Looks like none has answered you about this. I cannot give too much info as I have hardly use openGL outside of python. But as far as I understand pyopengl is pretty fast as it is just a tiny layer of python on top of C opengl code, what it is NOT that fast compared to C, is Python. This means that if you do very simple program your performance could be ok, but if there is a lot of python code to be executed every frame then you will find that the frame rate will drop. Keep in mind that opengl can be used within many different languages, each of them offers benefits and drawbacks. however, as i said before, i am not an expert at all. > thanks for any answer. i hope it helps best -- enrike |
From: Christopher A. <chr...@gm...> - 2006-06-12 19:19:41
|
I have used OpenGL in a number of languages (Python, Java, C, and C+=20 +). As Enrike said, PyOpenGL is just a thin layer over C libraries. I =20= found OpenGL to run pretty much at speed in Python. Python itself, =20 however, is quite a bit slower. So, to get the best performance, you =20= want to do as little computation as possible in Python itself. Make =20 heavy use of display lists and libraries like Numeric (or Numpy). It does take a little more thought to get good fps, but on the flip =20 side, Python is a great high level OO language and the support for =20 OpenGL is really quite good. Unlike some libraries (like the ones =20 I've used under Java), PyOpenGL really works almost identically to =20 the way that it does under C (with some nice Pythonic touches). This =20 is really exactly what Python is meant for - giving a nice high level =20= glue interface on top of high performance, low level C libraries. As a side note, I just used PyOpenGL to teach my graphics course this =20= spring and it worked great. My students could put all of their focus =20 on the OpenGL and the Python pretty much got out of the way. On Jun 12, 2006, at 10:57 AM, altern wrote: > hi Tham > > Tham Ting Hoi escribi=F3: >> is pyopengl similar to opengl in its performace? > > Looks like none has answered you about this. I cannot give too much =20= > info > as I have hardly use openGL outside of python. But as far as I > understand pyopengl is pretty fast as it is just a tiny layer of =20 > python > on top of C opengl code, what it is NOT that fast compared to C, is > Python. This means that if you do very simple program your performance > could be ok, but if there is a lot of python code to be executed every > frame then you will find that the frame rate will drop. > > Keep in mind that opengl can be used within many different languages, > each of them offers benefits and drawbacks. > > however, as i said before, i am not an expert at all. > >> thanks for any answer. > > i hope it helps > > best > > -- > enrike > > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Maciej K. <ma...@dg...> - 2006-06-13 15:26:19
|
On Mon, Jun 12, 2006 at 05:57:56PM +0200, altern wrote: > Looks like none has answered you about this. I cannot give too much info > as I have hardly use openGL outside of python. But as far as I > understand pyopengl is pretty fast as it is just a tiny layer of python > on top of C opengl code, what it is NOT that fast compared to C, is > Python. That is correct, PyOpenGL is just a (technically) simple set of wrappers around the regular OpenGL calls in the OpenGL library. The overhead incurred by this extra (thin) layer is usually negligible for most applications. > This means that if you do very simple program your performance > could be ok, but if there is a lot of python code to be executed every > frame then you will find that the frame rate will drop. I agree, the main bottleneck will be your other code. Still, one can actually do quite a lot with Python and PyOpenGL, even if you desire interactive rates. Check out the (hundreds?) of games developed with PyGame (www.pygame.org), a library for writing games with Python and PyOpenGL. -- Maciej Kalisiak mac "at" dgp.toronto.edu www.dgp.toronto.edu/~mac |
From: Douglas S. B. <db...@br...> - 2006-06-13 15:43:55
|
On Tue, 2006-06-13 at 11:20 -0400, Maciej Kalisiak wrote: > I agree, the main bottleneck will be your other code. Still, one can actually > do quite a lot with Python and PyOpenGL, even if you desire interactive rates. > Check out the (hundreds?) of games developed with PyGame (www.pygame.org), a > library for writing games with Python and PyOpenGL. I did some testing on a 2-CPU system a few years ago (circa 2003) and found that my Python-loop which controlled an PyOpenGL display of a robot updated over 1,000 times a second [1]. Of course, as you do more in the Python loop, that time will drop. -Doug [1] http://dangermouse.brynmawr.edu/~dblank/papers/sigcse-03.pdf -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank |