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.
important to note that this only happens when you set a desired frameRate, ie,
ofSetFrameRate()
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!!!
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
if(newFrame){
// 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.
