Re: [pygame] Speed up image.tostring with OpenGL ?
I know nothing of toonloop, so I'm guessing here, but I think your problem is not what you think it is, and from your problem description, it's likely you are not using openGL in the way it is meant to be used. pygame.image.tostring is plenty fast, as fast as a pygame blit it's extremely unlikely it represents any kind of bottleneck whatsoever. If you want to test this yourself, temporarily hack your app to just keep sending the same string up to the card over and over again (i.e. eliminate the tostring call), and check your frame rate. I expect you'll see no difference at all. Your slowness is probably caused by either uploading textures to opengl being a relatively slow operation (this is true no matter how you got the bytes to send to it) and/or your program being blocked by the OpenGL queue processing when you try to change a texture which there are pending operations on. (you aren't reusing the same single texture over and over again, are you?) The speed of hardware acceleration really comes from 2 specific things - first is that you do complex operations on a set of textures which have already been uploaded to the card (meaning you make a lot of pixels draw with a relatively small set of vertex data being sent each frame), second is that you are taking advantage of parallelism by making the graphics card do work independently of your CPU (meaning you send commands that the graphics card can do on it's own time and won't block the rest of what your program does). If you upload a new image every frame, you are not able to take advantage of the first way in which hardware acceleration speeds things up (you are basically sending all the pixels over to the card). If you are changing the content of textures as the graphics card is trying to draw them, you are not able to take advantage of the second way (the cpu ends up having to wait on the card being done with the texture before it can change it) you are probably right to think the whole thing should be done in pygame, but there are probably ways you could speed stuff up if there is a good reason to stick with opengl. The best way to do this in opengl, would be to load all the distinct frames into textures ahead of time, and then draw through them. Barring that, you could probably make the routine at least twice as fast by rotating through a pool of textures (so that you are never waiting to change a texture as it's being drawn) Also, you should probably use RGB instead of RGBX (should take 3/4ths the bandwidth to the card), there's no point in sending a dummy byte to the graphics card, when it comes to uploading textures, total bytes sent is generally much much more important than alignment issues. On Sun, Jan 3, 2010 at 8:06 PM, Alexandre Quessy alexan...@quessy.netwrote: Hello Pygame users and developers ! Is there a way I can speed up the transfert from a surface to an OpenGL texture ? Right now, I use the pygame.image.tostring function, but it seems like converting the pixels to a Python str creates a serious bottle neck in my stop motion application... I think that it should either be implemented directly in Pygame, (best option) or done using something like ctypes in my application. If none of these option is not easy enough, I am thinking about switching to Gstreamer+GTK with the GdkPixBuf, instead of Pygame surfaces. An other option would be to rewrite the whole application in C++... Any suggestion to fix this in a way that is not too long ? My frame rate drops to 4 FPS when there are more than a few surfaces in my list. Please try Toonloop to test this out. It works well on Linux. If someone get it to work on Mac or Windows, I would need hints for packaging it for those OS too. I convert the surfaces to OpenGL texture in texture_from_image from the file http://bitbucket.org/aalex/toonloop1/src/tip/toon/draw.py on what is currently the line 42. -- Alexandre Quessy http://alexandre.quessy.net/
Re: [pygame] Speed up image.tostring with OpenGL ?
Hi, try using surfarray. To avoid converting the data to a python string. pyopengl supports numpy arrays to do this. Also, different graphics cards are optimised for different texture formats. It can easily be 2-8x faster to have the correct format for your driver/card combination. However modern cards are getting faster support for more formats. However, the string conversion is probably the one to get rid of. I know for certain this will speed things up a lot. # something like this... untested. w,h = surf.get_size() data = pygame.surfarray.pixels2d(surf) texture = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, texture) glPixelStorei(GL_UNPACK_ALIGNMENT,1) glTexImage2D(GL_TEXTURE_2D, 0, 3, w, h, 0, GL_RGB, GL_UNSIGNED_BYTE, data) # ... etc... Also to speed up image loading/decoding... import pygame.threads pygame.threads.init(8) surfs = pygame.threads.tmap(pygame.image.load, your_images) Another thing to do is to make sure you are reusing textures (if possible). Since allocating a new texture each time can be slow, so if you application allows it, reuse textures. cheers, On Mon, Jan 4, 2010 at 4:06 AM, Alexandre Quessy alexan...@quessy.net wrote: Hello Pygame users and developers ! Is there a way I can speed up the transfert from a surface to an OpenGL texture ? Right now, I use the pygame.image.tostring function, but it seems like converting the pixels to a Python str creates a serious bottle neck in my stop motion application... I think that it should either be implemented directly in Pygame, (best option) or done using something like ctypes in my application. If none of these option is not easy enough, I am thinking about switching to Gstreamer+GTK with the GdkPixBuf, instead of Pygame surfaces. An other option would be to rewrite the whole application in C++... Any suggestion to fix this in a way that is not too long ? My frame rate drops to 4 FPS when there are more than a few surfaces in my list. Please try Toonloop to test this out. It works well on Linux. If someone get it to work on Mac or Windows, I would need hints for packaging it for those OS too. I convert the surfaces to OpenGL texture in texture_from_image from the file http://bitbucket.org/aalex/toonloop1/src/tip/toon/draw.py on what is currently the line 42. -- Alexandre Quessy http://alexandre.quessy.net/
Re: [pygame] Pygame 1.9 Debian package
On Mon, Jan 4, 2010 at 5:29 AM, Alexandre Quessy alexan...@quessy.net wrote: Hello, What is the state of the Debian packaging for Pygame 1.9 ? Arjan Scherpenisse has updated the Debian files. The package can be found at http://bitbucket.org/aalex/toonloop1/downloads/ Please ask Arjan Scherpenisse at ar...@scherpenisse.net if the maintainer needs those files. Does the Pygame project have a Debian maintainer ? I would like Pygame 1.9 to be packaged with Ubuntu 9.04 and in the Debian Testing distro. Right now, it seems it is still pygame 1.8 that is there. I am in tthe process of looking for a mentor to eventually become a maintainer myself, so I wouldn't mind looking after the packaging of Pygame as well if necessary. I would really like Pygame 1.9 to be in Debian and Ubuntu, so that I can release Toonloop as well. Thanks ! -- Alexandre Quessy http://alexandre.quessy.net/ hi, it would be awesome if you updated the packaging for debian/ubuntu! I filed bugs last year for debian, ubuntu, maemo... however none of them have made an updated package. There are the old maintainer emails listed on the packages, so you may be able to email those people. However, it would be cool if you were the maintainer I think. Maybe setting pygame up in a ubuntu PPA would help them speed up the process of getting it in? Or maybe attaching a patch to the bug reports would also help. cya.
Re: [pygame] Bugtracking for the camera module?
On Mon, Jan 4, 2010 at 4:01 AM, Alexandre Quessy alexan...@quessy.net wrote: Hello, I have a few bugs and features requests to report for the camera module. I might be one of the user/developer that uses it the most, with Toonloop. In the bugtracker at http://pygame.motherhamster.org/bugzilla/ there is no component named pygame.camera. Also, there is no version 1.9 in the choices. There are only 1.8, svn or unspecified. Thanks ! -- Alexandre Quessy http://alexandre.quessy.net/ Hi, reporting them to the mailing list will probably get you more of a response I think. cheers,
Re: [pygame] Speed up image.tostring with OpenGL ?
The only other way I know how to make OpenGL textures is with NumPy, using the GL_FLOAT token. This may be better for your purposes--although the way I see it, converting a surface to a texture is going to involve a conversion no matter which way you do it. Note that it's much faster to *update* a texture rather than create a new one. If at all possible, this may be your best opinion to improve speed. I'm very skeptical that PyOpenGL actually works correctly. On my box (old 2.4 GHz laptop w/geforce 4), the classic nehe lesson 42 (drawing a maze to a texture) python port gives HORRIBLE framerates, judging by eye to be about 5 fps, no matter whether I'm using Python 2.4, 2.5, 2.6, and I've tried repeated reinstalls and upgrades of PyOpenGL. The maze drawing always stops prematurely too, but that may be a logic bug in the ported version. Has anyone else duplicated this problem? The original C version of lesson 42 works at full frame rate. My self-written programs have really bad framerates too, but I barely understand OpenGL so it's possible those are my own fault. Alan
Re: [pygame] Bugtracking for the camera module?
On Mon, Jan 04, 2010 at 12:29:50PM +, René Dudfield wrote: On Mon, Jan 4, 2010 at 4:01 AM, Alexandre Quessy alexan...@quessy.net wrote: Hello, I have a few bugs and features requests to report for the camera module. I might be one of the user/developer that uses it the most, with Toonloop. In the bugtracker at http://pygame.motherhamster.org/bugzilla/ there is no component named pygame.camera. Also, there is no version 1.9 in the choices. There are only 1.8, svn or unspecified. Thanks ! -- Alexandre Quessy http://alexandre.quessy.net/ Hi, reporting them to the mailing list will probably get you more of a response I think. cheers, I updated the bugtracker to add the 1.9 version and the pygame.camera module. If there is anything else missing, just say so, and I can fix it. Although Rene is correct, the mailing list does tend to get faster results :) --- James Paige
Re: [pygame] Speed up image.tostring with OpenGL ?
2010/1/4 R. Alan Monroe amon...@columbus.rr.com The only other way I know how to make OpenGL textures is with NumPy, using the GL_FLOAT token. This may be better for your purposes--although the way I see it, converting a surface to a texture is going to involve a conversion no matter which way you do it. Note that it's much faster to *update* a texture rather than create a new one. If at all possible, this may be your best opinion to improve speed. I'm very skeptical that PyOpenGL actually works correctly. On my box (old 2.4 GHz laptop w/geforce 4), the classic nehe lesson 42 (drawing a maze to a texture) python port gives HORRIBLE framerates, judging by eye to be about 5 fps, no matter whether I'm using Python 2.4, 2.5, 2.6, and I've tried repeated reinstalls and upgrades of PyOpenGL. The maze drawing always stops prematurely too, but that may be a logic bug in the ported version. Has anyone else duplicated this problem? The original C version of lesson 42 works at full frame rate. My self-written programs have really bad framerates too, but I barely understand OpenGL so it's possible those are my own fault. Alan The problem with the at least some of the python nehe stuff is that calling extra functions isn't so bad under C (ie the original nehe tutorials) but with the latest pyopengl especially you're calling through ctypes so it should be written in a different way to optimise it for python really. I haven't actually looked at the tutorial you're talking about so I may be wrong.
Re: [pygame] Speed up image.tostring with OpenGL ?
On Mon, Jan 4, 2010 at 7:41 AM, R. Alan Monroe amon...@columbus.rr.comwrote: I'm very skeptical that PyOpenGL actually works correctly. On my box (old 2.4 GHz laptop w/geforce 4), the classic nehe lesson 42 (drawing a maze to a texture) python port gives HORRIBLE framerates, judging by eye to be about 5 fps, no matter whether I'm using Python 2.4, 2.5, 2.6, and I've tried repeated reinstalls and upgrades of PyOpenGL. The maze drawing always stops prematurely too, but that may be a logic bug in the ported version. Has anyone else duplicated this problem? For me, the Python version of 42 runs at a perfectly decent framerate (2.4GHz GeForce 7600M). Sounds like a separate issue from this one though. The original C version of lesson 42 works at full frame rate. My self-written programs have really bad framerates too, but I barely understand OpenGL so it's possible those are my own fault. Alan Ian
