WarpIntoMe benchmarks

Hi all,

I’m running a game I’ve made in openframeworks that renders 32-64 boids that react to some computer vision (including warpintome) on a mac, and I’ve got some performance issues.

warpIntoMe+blur+blob tracking+boids = 15fps (desired: 30fps)

If I unplug the firewire: 30fps

no blur or warping+blob tracking+boids = 20-21fps

no blur or warping+blob tracking+boids+Vsync explicitly turned off = 19-20fps

no blur or warping + blob tracking + boids + Vsync explicitly turned on = 20/21fps

killing all other processes, and running the app gives me another 2fps.

I’m running this off a 1.33Ghz G4 Powerbook 1.25GB RAM.

A 1.6Ghz Core Solo Mac Mini (512MB RAM) gives 22-23fps when running everything (vs. 15fps on the G4).

The video I’m warping is 320x240 B&W

I’m using theo’s updated computer vision code found here:

so I’m just wondering: should I just run this thing on a PC? I’m going to try some additional benchmarks on other machines this afternoon…

any thoughts, hugely appreciated!


-C :slight_smile:

have you tried to patch the FPS bug?

if you are doing a lot of stuff in update() the framerate decreases without the patch.


important to note that this only happens when you set a desired frameRate, ie,


b/c the system miscalculates how long to sleep (and you get framerates slower then you ought to).

it’s doesn’t happen (slow down) if you don’t set a target frame rate or if you are operating slower then your target frame rate (ie, if your true FPS is 20 and you said ofSetFrameRate(30)… because we don’t sleep at all ). the situations in which is it does slow down, is when you are faster then your target rate and you are doing a ton of stuff in idle.

this is fixed in 0.05 – and via the linked patch. thanks much joerg!!!


:smiley: :smiley: :smiley: :smiley: :smiley:

You need to run it on a intel soo much faster. I get about 90++ fps

I’ve found that not setting a desired framerate usually results in better performance (even in 005 which I’ve been using since the London workshop)

Another trick is to call ofSetBackgroundAuto(false); in setup(). I also use a newFrame flag in draw() to only draw when absolutely necessary so everything in draw is wrapped inside a conditional.

void testApp::draw(){ //ends up looking like this  
        // draw stuff here  
        newFrame = false;  
    } //end if(newFrame)  

In update() I set newFrame=true when I want a screen draw.

The effect of this has been pretty amazing and in one app the framerate when from 45-60fps to 800+ fps - okay so fps isn’t really a great measure but this does highlight how expensive clearing and drawing out the screen buffer can be, and how much computation time you can get back. Depending on your app you may have to explicitly draw background colour boxes over text display areas (without clearing you get a mish mash history with the the latest draws ontop) but you should probably still get a performance gain.

Hope this helps.


I’ve found that not setting a desired framerate usually results in better performance (even in 005 which I’ve been using since the London workshop)

note that the version from the london workshop probably didn’t have that fix in it… it was added later I think. should be all good in the real 0.05…

nice tricks, very old school :slight_smile: - zach