I have an iPhone program that runs a series of Get/Set Pixel functions on a texture. Today, I tried optimizing the program by replacing these with SetPixels() and was surprised to see a performance drop of about 5 FPS.
My texture is 512x256 with no mip mapping. Every frame I ran 18 GetPixel calls and for each, depending on the result, possibly a SetPixel call. So, potentially as many as 36 per frame. My alternative was to create an array colors[ ] using GetPixels at Start() and use these functions to edit it:
float GetColor(int x, int y){
return colors[y * dimentions[0] + x].a;
}
void SetColor(int x , int y){
colors[y * dimentions[0] + x][3] = 0;
}
Then, in Update(),
if(Time.frameCount % 2 != 0){
texture.SetPixels(colors,0);
texture.Apply(false);
}
To me this looked like it would obviously be the faster alternative, but it was much slower. What’s the bottleneck here?
you won’t get any higher FPS as long as you have apply in update.
Apply reuploads the texture again and doing that multiple times per second basically stalls the graphics chip.
you can do that once in start to setup the texture, but trying to fake realtime changes like that will not work
That’s not true - I can increase performance (by about 5 FPS) if I cut out 17 of the 18 Get/Set calls. So obviously these take some processing, not just Apply().
Any kind of direct memory access has an impact. Especially if it is done through further array access and multi dimensional arrays.
But a major hit is still the fact that you update the texture and replace the array every second frame
I just wanted to know why, for me, SetPixels seemed to be slower than SetPixel while the docs say it should be the other way around.
Which one is faster depends on what you do.
did you measure if its really the setpixels part thats slower, not the actual code that fills the array?
The array stuff isn’t free, I don’t think, but the SetPixels call is what makes the biggest difference.