ofTranslate() massive FPS drop on Ubuntu 16.04

My fps drops proportionally to the distance i do an ofTranslate(). Have you had any similar issues?


That is truly odd … do you have some code to share? Is it possible there is a for loop or something that is repeating a task based on the distance variable? Because AFAIK, ofTranslate is just a simple matrix operation … the magnitude of the translation vector shouldn’t increase the number of math operations or processing time … but some other section of code that scales with distance could certainly cause a slowdown. But, stranger things have happened!

If it’s not something like @bakercp describes, which should be what you are facing, I’ve had issues across all platforms like this massive fps drops, when alpha blending is enabled, and drawn objects on opengl cause a graphics bottleneck that causes the massive fps drop. also check culling, lightning, etc.

No loop :confused: its just running once in void draw(); But I think I’ve found the issue!

I moved the whole part out of the class that was running it and drew it directly in void draw(). It i drew an image in the class and had ofTranslate in void draw() i got lag. If I moved the image and drew it in void draw() instead i got 0 lag. So it seems it has to do with the context of where I draw my image after the ofTranslate.

I removed everything so the class function was just this thing. I got lag when drawing this thing after ofTranslate but not if I draw the img directly in void draw()…

void myClass::drawMap(int _width, int _height){

Edit: Ok looks like I just have to resize my images in setup and not in draw. Never had that issue in oF, but no problem!

1 Like

When you say resize, do you mean calling ofPixels::resize() or ofImage::resize()? Those would definitely slow things down depending on the parameters you pass. But just changing the parameters to ofImage::draw() is still a pretty fast texture scaling operation …

This is how i did it first.

void draw(){
    img.draw(0, 0, ofGetWindowWidth(), ofGetWindowHeight());

And this way it ran without any problem.

void setup(){
    img.resize(ofGetWindowWidth(), ofGetWindowHeight());

void draw(){
    img.draw(0, 0);

The second is definitely more efficient since it resizes once in RAM, especially if your initial image was really large. It’s not clear why the first would get slower with a translation, unless it comes down to an issue of visibility, culling, render, etc as @coding noted. It is likely a quirk with the linux GL driver as your original code certainly wasn’t “wrong”.

Thanks for the follow up!

ofGetWindowWidth/Height as well as ofGetWidth/Height might be slow on certain platforms, if you are doing that a lot of times per frame that might be the cause, try calling ofGetWindowWidth/Height outside of the loop and then using the value you got throughout the frame

I’ve redone it so I set it once in setup and it seems to run better.