Chrome + HTML5 gives better performance than Pyglet

[mclovin]

Hello all.

For the past couple of days I have been implementing a series of
particle animations and through it, learned a lot about how to make a
pyglet program achieve a nice speed.

However, today I decided to port my code over to HTML5's canvas tag
and see what would happen. I wasnt entirely certain that it would be
*that* great since to get 60FPS in pyglet I had do some work in C. to
my surprise, Canvas ran faster than pyglet. in pyglet I had to have
2500 particles to get 60fps, however in Canvas I could scale it up to
7500 particles and get a solid and fluid 60FPS.

I did a lot of work in pyglet making it scale that high.

I know that one of my main things slowing down pyglet was calculating
new coordinates, but after I implemented that in C, it took a mere .
001 seconds to calculate the new coordinates of ALL the points. So the
main slow down is now Rabbyt drawing the points (and Rabbyt is about
5x faster than Pyglet's sprites in this instance).

The points are currently png images of circles in Rabbyt Sprites. I
got about a 10% speed decrease when I moved from a vector list of
GL_POINTS to using a png image w/ Rabbyt. but i can scale the images
easily making one point bigger than the rest, something you cant do
with a vertex list full of GL_POINTS. and 10% doesnt at all make it
come close to HTML5's Canvas.

Now when I run it in HTML5 canvas, I still use png images because it
gives about a 40% speed gain then having the canvas calculate arcs.

Anyways, I am just horribly dissappointed by Pyglet. I used it for
about a year and always just excused some of its performance lags
because it was a scripting language. but a scripting language in a
browser kicks Pyglet's *$$

Also one should note that when I run it in chrome it runs at a stable
60FPS, but in FireFox 3.5, it runs at about 2FPS. So the browser does
make a difference.

Also you should note that straight up w/o my C implementation to
calculate coords Pyglet gets about 11 FPS on 2500, and with standard
pyglet sprites, about 8 FPS. the script isnt complicated at all so its
not like there is a black hole where i messed up the coding which is
sucking up space, it is all Pyglet's slow render speed. I profiled my
python code extensively and the rendering is the slowest part.

So I just wanted to get some of your thoughts on this. I know that
HTML Canvas is just 2D, and pyglet can do a lot more, but still,
javascript won in a performance contest against python.. and I find
that both sad and frightening that python is still so slow, at least
at rendering stuff.

[Richard Jones]

On 24/08/2009, at 1:07 PM, mclovin wrote:
> I find that both sad and frightening that python is still so slow,
> at least
> at rendering stuff.

This isn't a new discovery I'm afraid. It's been stated before that
pyglet is no good at systems like this (in particular particle
systems) where there's a large number of changes being made to OpenGL
data structures in a single frame. The Python / ctypes overhead is
just too great, as you've discovered.

I recommend the lepton particle system implementation which I've
previously used to good effect and it handles way more particles than
you're describing here.

http://pypi.python.org/pypi/lepton

Richard

[mclovin]

I'll check that out. but I chose Rabbyt because it supposedly made
less ctypes calls so i was hoping that would help. Ill try out lepton
and see how much that helps.

[Richard Jones]

On 24/08/2009, at 3:04 PM, mclovin wrote:
> I'll check that out. but I chose Rabbyt because it supposedly made
> less ctypes calls so i was hoping that would help. Ill try out lepton
> and see how much that helps.

AFAIK Rabbyt works by creating GL display lists under the covers. If
that's the case (it certainly was when the project started) then it's
not really suited to particle engines either.

Richard

[mclovin]

I tried out lepton, and went through some of your examples. Bouncy.py
is mainly what I needed (colorful balls at about 10px wide), but was
dissappointed at the low framerate: 22FPS at 1000 balls and at your
standard 100 balls it runs at a unsteady 40-47 FPS. with those few, i
would have expected a stable 60, if not 70 (vsync) FPS. which is odd
because the tunnel example seems to operate with many more particles.
so is there a reason bouncy.py is slow?

[René Dudfield]

hi,

Javascript in chrome is very fast and optimized.

Python is very slow in comparison... the python developers haven't
really sped it up enough (yet). However I think, and hope that it
will get better soon.

Have you tried using psyco? That generally speeds up particle
systems.

Psyco version 2.0 is out recently which is better than the old 1.6.
http://groups.google.com/group/comp.lang.python.announce/browse_thread/thread/446e7beca1f5692b
however the webpage hasn't been updated properly to say it exists, or
that it's hosted on a different svn.

A pygame sprite demo in software gets 47fps with 1000 sprites on my
laptop, with psyco. Without it, it gets 22fps or so.
python -m pygame.examples.testsprite -psyco -FastRenderGroup 1000


I had good luck with a numpy based particle system. Note, use v1.3
since before that there are bugs which make writing particle systems
harder (records don't work as well).

GPU particle systems are the way to go for best speed of course... in
which case you'll be using GLSL/etc instead, not javascript or python.

[Florian Bösch]

On Aug 24, 5:07 am, mclovin <hanoo...@gmail.com> wrote:
> Anyways, I am just horribly dissappointed by Pyglet. I used it for
> about a year and always just excused some of its performance lags
> because it was a scripting language. but a scripting language in a
> browser kicks Pyglet's *$$

It's not pyglets fault really.
1) ctypes FFI calls are slow
2) Chrome JS isn't really a "script" language, it gets compiled down
to x86/x64 machine code

However, 7500 particles is not so much. Doing the draw loop in C I get
to 20'000 particles @ 60FPS. See http://codeflow.org/particles.tgz,
which in essence is

void quad_draw(Quad* quad){
glPushMatrix();
glTranslatef(quad->x, quad->y, 0);
glRotatef(quad->rotation, 0, 0, 1);
glScalef(quad->size, quad->size, 0);
glBegin(GL_QUADS);
glTexCoord2i(0, 0);
glVertex2i(0, 0);
glTexCoord2i(1, 0);
glVertex2i(1, 0);
glTexCoord2i(1, 1);
glVertex2i(1, 1);
glTexCoord2i(0, 1);
glVertex2i(0, 1);
glEnd();
glPopMatrix();
}

over and over again.

[Tristam MacDonald]

On Mon, Aug 24, 2009 at 6:05 AM, Florian Bösch <pya...@gmail.com> wrote:

On Aug 24, 5:07 am, mclovin <hanoo...@gmail.com> wrote:
 > Anyways, I am just horribly dissappointed by Pyglet. I used it for
> about a year and always just excused some of its performance lags
> because it was a scripting language. but a scripting language in a
> browser kicks Pyglet's *$$

It's not pyglets fault really.
1) ctypes FFI calls are slow
2) Chrome JS isn't really a "script" language, it gets compiled down
to x86/x64 machine code

 

QFE. V8 is one of the most heavily optimised interpreters on the planet, and cuts a lot of corners - thus why it only runs on x86 machines.

However, 7500 particles is not so much. Doing the draw loop in C I get
to 20'000 particles @ 60FPS. See http://codeflow.org/particles.tgz,
which in essence is

I had to switch that to vertex arrays to achieve that sort of performance on my integrated card - it might perform even better on your system like that.

--
Tristam MacDonald
http://swiftcoder.wordpress.com/

[Florian Bösch]

On Aug 24, 1:41 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> I had to switch that to vertex arrays to achieve that sort of performance on
> my integrated card - it might perform even better on your system like that.

Care to post the code?

[mclovin]

On Aug 24, 5:02 am, René Dudfield <ren...@gmail.com> wrote:
> hi,
>
> Javascript in chrome is very fast and optimized.
>
> Python is very slow in comparison... the python developers haven't
> really sped it up enough (yet). However I think, and hope that it
> will get better soon.
>
> Have you tried using psyco? That generally speeds up particle
> systems.
>

> Psyco version 2.0 is out recently which is better than the old 1.6.http://groups.google.com/group/comp.lang.python.announce/browse_threa...

> however the webpage hasn't been updated properly to say it exists, or
> that it's hosted on a different svn.
>
> A pygame sprite demo in software gets 47fps with 1000 sprites on my
> laptop, with psyco. Without it, it gets 22fps or so.
> python -m pygame.examples.testsprite -psyco -FastRenderGroup 1000
>
> I had good luck with a numpy based particle system. Note, use v1.3
> since before that there are bugs which make writing particle systems
> harder (records don't work as well).
>
> GPU particle systems are the way to go for best speed of course... in
> which case you'll be using GLSL/etc instead, not javascript or python.

using psyco's profiler breaks pyglet and disallows input. but i
already had psyco built into it. like i said, it only took about .001-.
0005 seconds for it to calculate everything (for 60FPS 1/60=.016
seconds) so the main thing slowing it down is rendering not
calculations.

On Aug 24, 5:05 am, Florian Bösch <pya...@gmail.com> wrote:
> On Aug 24, 5:07 am, mclovin <hanoo...@gmail.com> wrote:
>  > Anyways, I am just horribly dissappointed by Pyglet. I used it for
>
> > about a year and always just excused some of its performance lags
> > because it was a scripting language. but a scripting language in a
> > browser kicks Pyglet's *$$
>
> It's not pyglets fault really.
> 1) ctypes FFI calls are slow
> 2) Chrome JS isn't really a "script" language, it gets compiled down
> to x86/x64 machine code
>
> However, 7500 particles is not so much. Doing the draw loop in C I get

> to 20'000 particles @ 60FPS. Seehttp://codeflow.org/particles.tgz,

> which in essence is
>
> void quad_draw(Quad* quad){
>     glPushMatrix();
>     glTranslatef(quad->x, quad->y, 0);
>     glRotatef(quad->rotation, 0, 0, 1);
>     glScalef(quad->size, quad->size, 0);
>     glBegin(GL_QUADS);
>     glTexCoord2i(0, 0);
>     glVertex2i(0, 0);
>     glTexCoord2i(1, 0);
>     glVertex2i(1, 0);
>     glTexCoord2i(1, 1);
>     glVertex2i(1, 1);
>     glTexCoord2i(0, 1);
>     glVertex2i(0, 1);
>     glEnd();
>     glPopMatrix();
>
> }
>
> over and over again.

wow, i actually didnt know that at all. I guess now i learned why some
javascript behaves differently in V8 than in FF.

but yeah, i just thought that using HTML5 and canvas would be
logically slower. When you think about it, It has all the DOM
overhead, and i dont know how they draw the canvas but i would assume
which ever way they draw it would have been slower

[Tristam MacDonald]

Here - though you probably have to revert make.sh to work on non-Mac systems.

[Casey Duncan]

Bouncy has a lot more collision interaction going on than tunnel does.
Also it uses "dumb" GL_POINTS to draw, which can be pretty slow.
Disabling the bumper collisions (comment out line 81) seems to help
performance a lot with larger number of particles. So presently lepton
is not as fast as I'd like when you have lots of particles interacting
with multiple domains. If that's something you really need, you may be
able to convince me to prioritize it 8^)

-Casey

[Florian Bösch]

On Aug 24, 4:54 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> > On Aug 24, 1:41 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> > > I had to switch that to vertex arrays to achieve that sort of performance
> > > on my integrated card - it might perform even better on your system like
> > > that.

> Here - though you probably have to revert make.sh to work on non-Mac
> systems.

Indeed that runs a bit faster, that gives me 65000 particles @ 60FPS,
also I added a bit of animation in this iteration :)
Funny though, doing the same trough pyglets VBO wrapper is 3-4x
slower.

http://codeflow.org/particles2.tgz

[Casey Duncan]

VBOs are really designed to optimize more static geometries, they can
be used to optimize certain parts of particle rendering (like texture
coordinates for non-animated particles, and maybe colors), but are not
really a win over the old venerable vertex arrays for vertices. Of
course, in theory they offer some advantages because the GPU owns the
memory management, and can therefore make assumptions about the
lifetime of the allocation that cannot be made with vert arrays.
However, whether that translates into better performance in the real
world is debatable.

Now for GPU-based particle systems they can be very useful because the
input geometry can be made static and simply mutated by shaders over
time. Ultimately I think this is a hack though, and the real answer is
likely geometry shaders.

-Casey

[Florian Bösch]

On Aug 24, 8:34 pm, Casey Duncan <casey.dun...@gmail.com> wrote:
> Now for GPU-based particle systems they can be very useful because the
> input geometry can be made static and simply mutated by shaders over
> time. Ultimately I think this is a hack though, and the real answer is
> likely geometry shaders.

GPU based Particle systems are very fast, but they can't do much in
the way of interesting behavior.
For instance, a common use of particles is smoke. Ideally smoke
particles would follow some simple aproximation of navier-strokes
equations, and the boundary conditions would be a collision mesh.
There is no way to perform a collision detection on the GPU.

[Casey Duncan]

It is in fact possible to create a particle system on the GPU complete
with collision detection and "interesting" behavior. It requires using
render-to-texture techniques with floating point textures. In fact the
first google hit on "gpu particle system" is a presentation on such a
system.

That said, it doesn't look very easy 8^)

-Casey

[Tristam MacDonald]

On Mon, Aug 24, 2009 at 3:18 PM, Casey Duncan <casey....@gmail.com> wrote:

It is in fact possible to create a particle system on the GPU complete
with collision detection and "interesting" behavior. It requires using
render-to-texture techniques with floating point textures. In fact the
first google hit on "gpu particle system" is a presentation on such a
system.

That said, it doesn't look very easy 8^)

It is *a lot* easier to do in CUDA/Stream/Compute/OpenCL, rather than hacking around with render-to-texture. Once OpenCL ships on major platforms (i.e. beginning with Snow Leopard), I expect to see a lot more of that sort of thing.

A good example is running Mirror's Edge on an NVidia graphics card - the CUDA-powered PhysX backend does a beautiful job of animating every piece of cloth and paper on the GPU.

[mclovin]

Hmmm... maybe my computer is just slow but your code runs at 7-8
frames per second on my 64bit ubuntu. but my computer isnt even old,
its an aluminium macbook with a Nvidia 9400. not the most powerful
card in the world, but it is pretty decent

[Richard Jones]

On 25/08/2009, at 10:28 AM, mclovin wrote:
> Hmmm... maybe my computer is just slow but your code runs at 7-8
> frames per second on my 64bit ubuntu. but my computer isnt even old,
> its an aluminium macbook with a Nvidia 9400. not the most powerful
> card in the world, but it is pretty decent

What video drivers are you using (glxinfo "OpenGL renderer string")?
What FPS do you get out of glxgears? If you're coding this stuff by
hand and not using pyglet's texture management code then are your
texture dimensions power-of-2?

Richard

[Florian Bösch]

On any account, drawing 65k particles by use of of a few small bits of
C instead of 6k particles in V8 is something you can't do in chrome.
Case in point I wouldn't code for Chrome because of that.