Faster cocos sprites

versión en castellano

In the last blog entry we seen that cocos 0.4.0 sprites were more slow than the pyglet 1.1.4 ones. Lets see if cocos code can be improved to close the performance gap.

Approaching the problem

Python includes the cProfile module which allows to measure how much time is spent in each callable, so I added a few lines in the scripts to generate profile data.

Running the scripts produces a lot of statistics; to explore these I used RunSnakeRun, a visualizer for cProfile stats. It represents the call tree as nested boxes, with box area proportional to time spent in the callable.

Playing a bit with the visualization options, I got two images that seems interesting; combined and annotated they look as:

sprite performance in cocos and pyglet

versión en castellano

How many sprites can I show with acceptable frames per second (fps) ?
What can I do for better performance ?
I will set up a test situation, measure and see what can be learned.

Test situation, in pseudocode:

• initial state:  add n balls with nearly random position and velocity; initial position into the screen rectangle
• update(dt): at each frame, each ball updates position with the classical
  if the ball touches the border, it bounces so as to not go off-screen.

screenshot

First implementation:

The simpler possible, the scene will have a sprite list, to draw the scene the list is iterated drawing each sprite with its own draw method.
After coding and runs I got the data

Using the interactive interpreter Dreampie and matplotlib to plot the data:

Ouchhh! We have problems ?

As a rough guide, visuals are smooth at 60 fps. Playability varies, fast paced games or the ones that need very precise coordination can need 60, others can be acceptable at 20 fps.
So, say 30 fps is our minimum acceptable fps, and 60 is our fancy desired fps.
Looking at the test data, we should limit the quantity of sprites in our game to

• 100 sprites to get the minimum acceptable fps
• 50 sprites to get the fancy desired fps

That looks scarce, right ?
The tutorials and mail lists for cocos and pyglet tells that using batch s gives better performance, so lets try with that.

Second implementation:

Here we essentially add the sprites into a batch object, the scene is draw by the batch's draw method.
Coding and running the new implementation we get the data:

Ploting like before fps vs sprite quantity:

Much better:

• With pyglet, for minimum acceptable fps we can use up to 1000 sprites; for fanciness up to 500.
• With cocos, for minimum acceptable fps we can use up to 500 sprites; for fanciness up to 250.

On hold!

cocos sprites are a sublcass of pyglet sprites, why they perform poorly relative to pyglet ?
Being a cocos comitter make me itch to investigate the issue, and hopefully fix it.

So I will put on hold this blog entry and follow with one talking about the process of investigating and fixing the issue.

There are more interesting things to test and tell about sprites and batches, and I will revisit later.

Test conditions:

• cocos 0.4.0 release , pyglet 1.1.4 release
• windows xp , python 2.6.5
• amd athlon 64 x2 5200, integated gpu ati 3200

Code and media used in this test can be downloaded here.