Improve OpenGL usage especially for python-opengl >= 3.x

[GoogleCodeExporter]

Some optimizations could take place by following the tips given at:
http://www.siafoo.net/article/58

I'm sure we could gain from this.

Original issue reported on code.google.com by evily...@gmail.com on 5 Dec 2008 at 2:13

[GoogleCodeExporter]

this would be definitely a step forward, though it is much, much work

optimizing the pyOpenGL-code could get pyOpenGL3 the same performance as the old
2.*-version

here's a quote from the pyOpenGL-developer
(http://blog.vrplumber.com/index.php?/archives/2267-PyOpenGL-3.0.0c1-Available-f
or-Testing.html):
If you are using deprecated functionality (such as using individual calls for
vertices, colours and the like) you may find PyOpenGL 3.x unacceptably slow.  
You
should convert your code to use array-based drawing (or vertex buffer objects), 
as
OpenGL 3.1 and beyond are intending to drop support for the legacy APIs.

to sum up: everything between glBegin() and glEnd() is slow and should be 
replaced by
some other code
and there are way too much glBegin()s in fofix (approx. 100)

unfortunately i have no knowledge of openGL, so i can't really help with this
problem, i was just searching, why pyOpenGL3 has only the half performance as 
the old
version.

btw: this isn't really py2.5 specific, as you could also use pyOpenGL 3 with 
py2.4

Original comment by max26...@gmail.com on 22 Feb 2009 at 8:21

[GoogleCodeExporter]

Well, here's an example of drawing using arrays...

Before (direct mode):
  glBegin(GL_TRIANGLES)

  glColor3f(1.0, 0.0, 0.0)

  glVertex3f(0.0, 1.0, 0.0)

  glColor3f(0.0, 1.0, 0.0)

  glVertex3f(-1.0, -1.0, 0)

  glColor3f(0.0, 0.0, 1.0)

  glVertex3f(1.0, -1.0, 0)

  glEnd()

After (Array-style):
  triang_prim = [[0.0, 1.0, 0.0],[-1.0, -1.0, 0],[1.0, -1.0, 0]]
  triang_col = [[1.0, 0.0, 0.0],[0.0, 1.0, 0.0],[0.0, 0.0, 1.0]]

  glVertexPointerf(triang_prim)
  glColorPointerf(triang_col)
  glEnableClientState(GL_VERTEX_ARRAY)
  glEnableClientState(GL_COLOR_ARRAY)
  glDrawArrays(GL_TRIANGLES, 0, len(triang_prim))

Vertex Buffer Objects (VBOs) are even faster but if i understand correctly it 
would
be harder to "convert" FoFiX direct mode code snippets to VBOs. Where it's easy 
to
use VBOs, it is recommended.

Original comment by evily...@gmail.com on 23 Feb 2009 at 1:45

[GoogleCodeExporter]

Modified Font class to use vertex and texture numpy array pointers in r1089.

Original comment by evily...@gmail.com on 23 Feb 2009 at 5:41

[GoogleCodeExporter]

Using Numeric instead of numpy as of r1090. (numpy should be preferred for 
python2.5).
Another small conversion in Guitar class in r1091.

Original comment by evily...@gmail.com on 23 Feb 2009 at 6:24

[GoogleCodeExporter]

to worldrave:
PyOpenGL.3 needs the ctypes module (it is included in py2.5 and above), if u are
using py2.4, u need to install it:
http://downloads.sourceforge.net/ctypes/ctypes-1.0.2.win32-py2.4.exe?use_mirror=
surfnet

to evilynux:
i would prefer to add numpy to the list of required sources, because it would be
nonsense to change all code when switching back to numpy later (py2.5)

btw: how can i comment on a revision? are only developers able to do that?

Original comment by max26...@gmail.com on 23 Feb 2009 at 8:48

[GoogleCodeExporter]

Bah, no biggy as converting from Numeric to numpy is a piece of cake and could 
easily
be automated using a simple perl script or even a line of sed.

Original comment by evily...@gmail.com on 23 Feb 2009 at 1:22

[GoogleCodeExporter]

btw max26199, i don't know if non-developers can comment on revisions...

Original comment by evily...@gmail.com on 23 Feb 2009 at 2:35

[GoogleCodeExporter]

damit, it seems that there is a problem with PyOpenGL 3.0.0.c1 and numeric 
arrays
(have tested b8 and b6 too, Windows and Fedora) 
it crashes with an error: OpenGL.converters....

strange behavior, as there are some numeric classes in OpenGL.arrays

quote from the pyopengl-mailing-list:
There's even a legacy Numeric format handler,
though honestly I haven't got any setup for testing that it remains valid.

Original comment by max26...@gmail.com on 23 Feb 2009 at 4:15

[GoogleCodeExporter]

Errr... it's hard to satisfy every combination...
Should i use native [but slower] python lists instead?! (At least until we 
completely
move to pyopengl3.x and numpy)

Or should we force the move to numpy even while we stick with python2.4 and
pyopengl2.x? Any advice appreciated.

FWIW, i haven't encountered any crash under Debian unstable... weird 'cause it's
3.0.0~b6. 

Original comment by evily...@gmail.com on 23 Feb 2009 at 4:24

[GoogleCodeExporter]

i dont see any problem in using numpy (for Graphics, Svg and Scene could be 
updated)
and numeric (for the Audio.py) at the same time, and stay with py2.4 and 
pyopengl2.x
for now.

I think this would fit most systems.

Original comment by max26...@gmail.com on 23 Feb 2009 at 4:44

[GoogleCodeExporter]

If i remember correctly, we still need to use Numeric in some places as pygame 
< 1.8
doesn't fully support numpy. (I hope i'm wrong tho).

Original comment by evily...@gmail.com on 23 Feb 2009 at 4:51

[GoogleCodeExporter]

yep, thats the Audio.py part
for some reason that doesnt work with numpy
and pygame 1.8.1 doesnt work with py2.4
so yes, we still would need Numeric

Original comment by max26...@gmail.com on 23 Feb 2009 at 4:59

[GoogleCodeExporter]

@max26199, I confirm current trunk fails.
I bisected to r1090 and here the backtrace:

[...]
  File "/home/bruno/fof/fofix-hg/src/Font.py", line 156, in drawSquare
    glVertexPointerf(square_prim)
  File "//usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 1273, in __call__
    return self.finalise()( *args, **named )
  File "//usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 393, in wrapperCall
    pyArgs = tuple( calculate_pyArgs( args ))
  File "//usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 328, in
calculate_pyArgs
    yield converter(args[index], self, args)
  File "//usr/lib/python2.5/site-packages/OpenGL/converters.py", line 116, in __call__
    return self.function( incoming )
  File "//usr/lib/python2.5/site-packages/OpenGL/arrays/arraydatatype.py", line 51,
in asArray
    return cls.getHandler(value).asArray( value, typeCode or cls.typeConstant )
  File "//usr/lib/python2.5/site-packages/OpenGL/arrays/formathandler.py", line 15,
in __call__
    typ = value.__class__
AttributeError: ('__class__', <OpenGL.converters.CallFuncPyConverter object at
0x8ca1d2c>)

I tried with PyOpenGL-3.0.0b8 and 3.0.0c1
System:
python-2.5.2 on Gentoo linux
gfx: nvidia FX5700, driver 173.14.15

Bruno

Original comment by btarqu...@gmail.com on 23 Feb 2009 at 6:03

[GoogleCodeExporter]

Ok, i see two possibilities:
1) Use native [but slower] python lists;
2) Force a depend on numpy and use numpy arrays.

max26199: Would you mind testing numpy arrays?
* I'm assuming that you can quickly understand what to change in both Font.py 
and
Guitar.py. Am i wrong?

Original comment by evily...@gmail.com on 23 Feb 2009 at 6:29

[GoogleCodeExporter]

numpy arrays with PyOpenGl-3.* work fine (both py2.4 and py2.5).
? or what do you exactly mean with 'testing numpy arrays'? 

Original comment by max26...@gmail.com on 23 Feb 2009 at 7:10

[GoogleCodeExporter]

That's pretty much what it seems you've done... i meant modify my code to use 
numpy
and run FoFiX to see if it still crashes. If you did that affirmation w/o 
testing,
it's not much valid as theoretically PyOpenGL3.x should also be compatible with
Numeric (which is the case under Debian unstable... perhaps Numeric was patched 
tho).

Now, if only a knowledgeable Windows user would do the same test we'd be good.

Original comment by evily...@gmail.com on 23 Feb 2009 at 7:53

[GoogleCodeExporter]

We've been tossing enough additional dependencies in lately (mostly at my 
hands)...
for numpy I'd have to say go for it.  (Perhaps we should try to get rid of 
Numeric
the other places it's used if we do make the jump.)

pyOpenGL 3's intricate (and quite weird) import mechanisms (using the low-level
__import__() call!) have made packing up my experimental py2.5 Windows builds 
(using
pyOpenGL 3) a royal pain.  (Under 2.5 I too am running 3c1; under 2.4 I'm 
running
2.something-or-other.)  I did notice that it dragged in ctypes and numpy, which 
have
also been discussed on the comments of (I think) r1090.

Making things work even nicer than they already do under 2.5 under GNU/Linux is 
only
half the battle, though - we need to bring the Windows stuff up-to-date too.  A 
bit
off topic, but perhaps for Windows I should skip 2.5 and go right for 2.6?  (I 
do
know that I will then have a slew of old modules to recompile, but if I already 
did
it for 2.5...)

For now I'll be doing some testing of the most current changes on my Windows 
machine...

Original comment by john.stumpo on 23 Feb 2009 at 10:40

[GoogleCodeExporter]

i changed a lot of glBegin-End-Blocks to use the array-mechanism, but it seems 
that
it is much slower than the 'direct mode'. (used numpy)

here's the diff file: http://www.mediafire.com/?wk33yu2ly3n

i am going to test this some more tomorrow when i have time...

@john
as i see the 'big' problem on windows with py2.5 is playing songs with multiple 
oggs
(causing a segfault with the pyogg/pyvorbis-modules - i have tried to build 
them for
2.6 but there i get the segfault too)?
as of skipping 2.5: you shouldn't do that until there is a final/beta of numpy 
for
2.6 (ofc. only if it is being used)

Original comment by max26...@gmail.com on 23 Feb 2009 at 11:12

[GoogleCodeExporter]

Numeric = no longer supported, numpy = supported?

If that's the case... then it makes a lot of sense for us to migrate over to 
numpy
for future expandability and such.  This will only break the alpha testers, as 
the
modules will all be included in any beta / RC / final versions.  Besides, the 
alpha
testers should already be familiar with installing required modules to run from 
source.

I don't think it's a terrible thing to require alpha testers to download ctypes 
and
numpy in order to continue alpha testing, and we end up with a FoFiX that is 
more
compatible with future versions of Python and other dependencies.

Original comment by chris.paiano@gmail.com on 24 Feb 2009 at 1:38

[GoogleCodeExporter]

numpy is the successor to Numeric, which is no longer maintained.

It wasn't hard for me to get rid of Numeric in my working copy, throw in numpy, 
and
at the same time start experimenting with Python 2.6, though I just did a
quick-and-dirty port.  (So, Pascal: I'd like to see how you would have done 
it.)  The
difficult part was compiling numpy for 2.6, but naturally I'm going to spare 
all of
you the trouble and just upload my build, like I did with all of the 2.5 stuff. 
 Max:
It's not a case of incompatibility as much as one of there just not being a 
build up
for grabs.

Things are looking very much up right now, but guess which modules I still have 
left
to build... that's right, ogg and vorbis!  (Except that this time around I 
actually
have the same compiler Python itself was built with.)

From my experimentation so far, moving up is looking to be a fairly 
straightforward
process.  For those without a copy of 2.6, I'm going to upload a 2.6 build once 
I get
the dependencies sorted out.  If this works out nicely for everyone, I think we
should (at least for Windows) consider making the leap and skipping 2.5 
altogether.

Original comment by john.stumpo on 24 Feb 2009 at 3:15

[GoogleCodeExporter]

I can update the RequiredModule's Wiki then to include python2.4 Numpy as well 
as re-
add python2.4 ctypes again. (Added it this morning, but then removed it like an 
hour 
later as we thought we didn't need it after all. 

Original comment by worldrave111@gmail.com on 24 Feb 2009 at 3:32

[GoogleCodeExporter]

That is once we get the full list together for 2.5, and i'll just add all that.

Original comment by worldrave111@gmail.com on 24 Feb 2009 at 3:55

[GoogleCodeExporter]

Weirdly, Numeric+pyopengl3.x makes FoFiX crash on my 32bit CPU (and i've the 
same
sw/libs installed compared to my 64bit machine, oh well..).
Anyway we shall move to numpy.

@max26199: For some reason i can't seem to be able to apply your patch even tho 
it
looks like you've created it against r1090 (from the top of my head, anyway i 
tried
to apply it from the corresponding version mentioned in your patch). Alot of 
chunks
are failing. (Note that quickly going thru your patch i noticed you overlooked 
some
details. No worries, overall it's all good. It's unfortunate i can't apply it 
as-is
tho, can you please recreate it against r1091?)

In any case, you mentioned that performance are worst for you with those 
changes.
This worries me as theoretically it should be the opposite... 

Will we have to use VBOs everywhere to bring up pyopengl2.x-like performance w/
pyopengl3.x. We're fighting in order to match (not even improve) performance, 
this is
getting ridiculous... 

@john: i haven't made anything really special besides explicitly specifying the 
data
type for some arrays.

@chris: Nope, i'm not using pyglet but looking at Audio.py in the exp-py2.5 
branch i
notice that it's always using pygame.mixer.Sound directly. While that gets rid 
of
pyogg/pyvorbis, i noticed yesterday that we [would] also loose our capability 
to push
buffers to the Sound object (e.g. apply pitchbend effect). There's gotta be 
another
way to do this... pygame.mixer.Channel.queue doesn't seem appropriate either...

Original comment by evily...@gmail.com on 24 Feb 2009 at 3:18

[GoogleCodeExporter]

hmm... the patch file was created from r1091 - it works for me if i apply it on 
r1091
(Windows, TortoiseSVN)

could it be, that the reason for the slowdown with the array mode is: creating 
the
arrays?
i made some tests: recorded the frames from the first minute of a song (used
pyOpenGL-2.x)
try1: no drawing at all (removed all glBegin-...-glEnd code)
try2: my patchfile, but generate only the arrays (no glDrawArrays, no
glVertexPointerf...)
try3: r1087 (latest rev with direct rendering)

here's the curve: http://i44.tinypic.com/2cgitxl.png

there is very less difference between no drawing and r1087 - it will be hard to
improve performance..., maybe the whole code has to be refactored

maybe we really have to use VBOs, but thats getting difficult. (i looked at 
pyglet,
the 'competitor' of pyopengl, it has a nice api and includes functions for 
vbo's:
pyglet.graphics.vertex_list(...) - i am going to try that)

Original comment by max26...@gmail.com on 24 Feb 2009 at 4:50

[GoogleCodeExporter]

Those are interesting results!

But ouch, array creation seems pretty expensive... and seems to kill an eventual
performance gain. Should we be smarter and initialize the arrays once and only 
update
the required fields? It can become painful to track the different arrays tho.

In any case we are fighting on many fronts to improve performance and i expect 
great
stuff from issue 491 (hey there Chris, i hope i'm not putting too much pressure 
on
your shoulders. Do your thing, we'll see what comes out.).

Original comment by evily...@gmail.com on 24 Feb 2009 at 5:08

[GoogleCodeExporter]

In r1094 i've changed Guitar and Font classes to use numpy instead of Numeric.
I've also tried initializing arrays in __init__ and only change required fields 
at
render time. At least on this machine, this results in a 12% performance gain.

Original comment by evily...@gmail.com on 24 Feb 2009 at 5:38

[GoogleCodeExporter]

May want to make a new issue for some of these things as this doesn't look like 
it's
related to the py2.5 trunk (unless you guys are rethinking the way of migrating 
to
some new python version).

Original comment by ryanturcotte@gmail.com on 24 Feb 2009 at 6:29

[GoogleCodeExporter]

http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 > 
Numpy
for 2.4 for Windows link. Add that to Windows SourceFiles page?

Original comment by ryanturcotte@gmail.com on 24 Feb 2009 at 7:45

[GoogleCodeExporter]

Already done.

Original comment by worldrave111@gmail.com on 25 Feb 2009 at 12:13

[GoogleCodeExporter]

It does seem to be related to python2.4 still, since it crashes as of today's 
SVN 
until i installed Numpy for python2.4

I would love to add a list of python 2.5 module's to the Wiki though, some of 
us can 
also help out with testing and stuff.

Original comment by worldrave111@gmail.com on 25 Feb 2009 at 12:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok, altho switching from direct mode to array-based drawing is inevitable, the 
way i
do it turns out to be a bad idea.

Please see Mike Fletcher comment at:
http://blog.vrplumber.com/index.php?/archives/2267-PyOpenGL-3.0.0c1-Available-fo
r-Testing.html

Original comment by evily...@gmail.com on 25 Feb 2009 at 5:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have some changesets ready for some other alterations that are needed for 
2.5/2.6
(as most of you probably know I'm shooting for 2.6), including making pyOpenGL 
3 and
pygame 1.8.1 go through py2exe correctly and completely getting rid of Numeric.

Once I get all of the required modules working, I think we really should go 
right on
and jump up to 2.5/2.6 after testing.  I still do believe that it would be more
worthwhile to go
directly to 2.6, but that's just me.

Original comment by john.stumpo on 25 Feb 2009 at 5:16

[GoogleCodeExporter]

John, could you please make those available so i can have a look?

On a possible jump straight to python2.6, my biggest show stopper here is that 
it
hasn't even made it into Debian unstable yet. The latest information i had on 
this
was that the main python packager/guru wanted Lenny (as well as some of his 
Ph.D.
administration stuff) out of the way before uploading it to unstable. Lenny was 
just
released, so perhaps that can occur soon enough.

Speaking of getting modules to work, I'm still looking for a viable replacement 
for
PyOGG/PyVorbis that allows sound buffer modifications. As i mentioned above,
pygame.mixer.Sound plays OGG files fine but doesn't allow us to e.g. pass a 
buffer to
pitchbend then update buffer before pygame.mixer.Sound plays it. Perhaps we 
could use
pymedia.audio.sound or more radically AVBin?

Original comment by evily...@gmail.com on 25 Feb 2009 at 5:24

[GoogleCodeExporter]

Ah crap, i've deleted a comment by mistake (mismove while scrolling) and now i 
can't
identify nor recover it... Oh well, i don't even know whom comment it was but 
in any
case i'm sorry.

Original comment by evily...@gmail.com on 25 Feb 2009 at 5:29

[GoogleCodeExporter]

Much progress on the pygame 1.9, pyOpenGL 3, numpy, and Python 2.5/2.6 
transitions
has been committed in r1114.

Original comment by john.stumpo on 28 Feb 2009 at 6:40

[GoogleCodeExporter]

I think we really need to finish shifting to array-based drawing.  The reason 
is that
pyOpenGL 3 no longer directly calls OpenGL functions using its own extension 
modules
as 2 did (fast and direct!) but instead passes many functions through one or 
more
layers of Python that call OpenGL through ctypes.  Thus, we need to try to cut 
back
on the physical number of calls to certain OpenGL functions in 
performance-critical
areas of the code.  (glBegin is such a Pythonified function.)

The only problem most people on the forums are having with 2.6 is a drop in 
FPS, and
I think this is to blame for that.

Original comment by john.stumpo on 2 Mar 2009 at 4:47

[GoogleCodeExporter]

John: Good job with the Numeric -> numpy transition :-)
IIRC, while most of your changes were exactly what i had done in the exp-py2.5
branch, the SHA one wasn't part of it and it may have made a significant 
difference.

At least, now using py2.5+pyopengl3.x has become "playable" for me. I now get
anywhere between 20 and 60fps in-game while i use to have 30 to 38fps.

About array-based drawing... it may not be that simple. If we're only converting
direct-mode drawing to array-based drawing, we won't gain anything. To the 
contrary,
it will be slower because of the extra overhead caused by arrays. See comment 
24 by
max26199 (he also provides a patch).

Like Mike Fletcher told me (see
http://blog.vrplumber.com/index.php?/archives/2267-PyOpenGL-3.0.0c1-Available-fo
r-Testing.html),
we have to change the philosophy behind our drawing. This is not explicitly 
told by
Mike, but, as an example, instead of varying the x, y, z coordinates when doing
direct-mode rendering. Those should be fixed and the position should be modified
using e.g. glTranslate calls. That way, the coordinates can be pushed at
initializations allowing us to use Vertex Buffer Objects (VBOs).

VBOs are much much more performant as vertex/polygons coordinates are kept on 
the
videocard (no more huge data chunks sent to the videocard).

Now, this is the ideal case... How much of it can we implement... i guess this 
is a
case by case decision.

Finally, perhaps this is a good timing to implement a font rendering queue that
renders all the text at the same time?

Original comment by evily...@gmail.com on 2 Mar 2009 at 7:25

[GoogleCodeExporter]

"perhaps this is a good timing to implement a font rendering queue that
renders all the text at the same time?"

...I concur.

Original comment by chris.paiano@gmail.com on 3 Mar 2009 at 3:00

[GoogleCodeExporter]

I have no idea of python programming, but I do on OpenGL programming. I've 
understood
you are drawing each note modifying each coordinate of the mesh by hand, and 
issuing
glVertex orders, and that's the very slowest way to render. In order to speed 
things
up, even more in a languaje so CPU-dependent as python is, the fastest way is:
- Create ONLY ONCE one VBO for every DIFFERENT mesh on the game, on the setup 
(stage
loading).
- Use glTranslate/glRotate and glEnable(_texture_) before rendering on every 
frame
and every element.
- Call glDrawArrays to render the element and DO NOT TOUCH the geometry.

So the code in the render loop would look like:
[...]
  glBindTexture(fret1_texture)
  glVertexPointerf(note_mesh)
  glEnableClientState(GL_VERTEX_ARRAY)
  glDrawArrays(GL_TRIANGLES, 0, len(note_mesh))
[...]
NEVER EVER create an array/VBO INSIDE de render loop! It will kill performance 
BADLY.

I'm sorry it this is too obvious, but I've just got scared of what I've 
understood in
this issue, if its not been doing the way I've described first, I do apology.

Original comment by egon....@gmail.com on 27 Mar 2009 at 4:23

[GoogleCodeExporter]

Egon, yes, you are right. That's what i'm mentionning in my comment 39.
Relevant extract:
[...]instead of varying the x, y, z coordinates when doing
direct-mode rendering. Those should be fixed and the position should be modified
using e.g. glTranslate calls. That way, the coordinates can be pushed at
initializations allowing us to use Vertex Buffer Objects (VBOs).

Original comment by evily...@gmail.com on 27 Mar 2009 at 5:43

[GoogleCodeExporter]

Yes, I read your post, but I read too another poster who was converting the 
code to
vertex array and having no perfomance gains (even looses!), and if he was 
creating
the vertex arrays IN the render loop, that's the reason. Vertex arrays always 
have to
be created before the render loop.

Original comment by egon....@gmail.com on 30 Mar 2009 at 7:33

[GoogleCodeExporter]

Comitted one little step at improving array based drawing in r1327.
All i can do for tonight, textures and colors should be next.

Original comment by evily...@gmail.com on 16 Apr 2009 at 3:46

[GoogleCodeExporter]

Issue 287 has been merged into this issue.

Original comment by evily...@gmail.com on 18 Apr 2009 at 5:43

[GoogleCodeExporter]

Issue 778 has been merged into this issue.

Original comment by death.au on 24 May 2009 at 9:13

[GoogleCodeExporter]

This is specific to pyopengl 3.x, not python, removing py2.5 label.

Original comment by evily...@gmail.com on 23 Jun 2009 at 2:37

• Changed title: Improve OpenGL usage especially for python-opengl >= 3.x
• Removed labels: Milestone-Python2.5-Support

[GoogleCodeExporter]

Should this be bumped up to Milestone-Release-4.0.0?
(preferably 3.120, but it's most likely going to be easier to do alongside a 
rewrite
of guitarscene.py and similar, which I imagine is a while off)

Original comment by death.au on 14 Jul 2009 at 8:58

[GoogleCodeExporter]

Actually this should be an ongoing effort (mostly from 4.0.0) to write OpenGL 
3.0/3.1
code with good practices in mind.

Original comment by evily...@gmail.com on 14 Jul 2009 at 11:44

[GoogleCodeExporter]

Note that I've tried to apply these principles in both VideoPlayer.py and
AnimationPlayer.py .

Original comment by evily...@gmail.com on 25 Sep 2009 at 2:42

• Changed state: Started