koobas.hobune.stream
Is it expensive to use SetPixels() every frame for a second or 2?
Hi,
I'm wondering if it is expensive to SetPixels() every frame? I have a GUI texture where I want to move a portion ( button of 100x100 pixels ) of it off screen while keeping the rest intact using SetPixels, but is this expensive?? I'm assuming that it is essentially storing the same amount of info as a texture of 100x100 pixels ( array of 10,000 colours, please correct me if I'm wrong ). And SetPixels, I assume, is iterating through the array of 10,000 colours whenever you use it.
Anyways, this idea stems from having one draw call for the whole GUI while still having the ability to move each individual GUI object (portion of the texture). Even though it would keep all GUI in one texture and one GameObject that never moves, will the SetPixels() and the memory that the array stores kill performance if used too much??? This is a save-on-draw-calls vs. is-it-causing-more-trouble-than-its-worth scenario....
Thanks in advance
It is an expensive operation, but why not just put it on the target device and test it to find out if it is too expensive? If you don't see a frame rate drop, you can also call SetPixels() multiple times in a loop, increasing the number of loops until you see a drop in FPS. This will give you a clear pictured of how close to the edge your code will push the fps for that device.
I assumed it was heavy to write to a texture, but I was thinking that if there are, say, 6 or more GUITexture game objects on screen with a couple of them being moved from time to time, something like this would $$anonymous$$imize the GOs/Textures and free up all those draw calls.. Anyways, I will give it a test on my iPhone when I have a moment and I will post my results here for anyone who's interested in the future. Thanks
Looks like I can make this happen with GUI Groups, BeginGroup() and EndGroup(). I'll try that as well
EDIT: Nope, every group with a texture is another draw call
I'm going to venture it's not worth it. The problem with set pixels isn't how many pixels are modified or mem is used in as much as it is with how slow it is to call GetPixels (and SetPixels to a lesser extent), and you can only call SetPixels to update the entire mip level, so you are likely going to call GetPixels first, change the area you are interested in, then call SetPixels. This is very slow. Even if you just call SetPixels with a preset buffer every time, you are pushing memory from the CPU to the GPU. When you use the rendering pipeline by transfor$$anonymous$$g the position of a group of pixels, it's probably orders of magnitude faster. There is no movement between memory as long as the texture has already been loaded in the Vid card memory and you aren't thrashing. The better solution to achieve a single draw call with GUIs is to use a texture atlas.
My conclusion is this:
GetPixels can in fact do what I'm asking on mobile platforms and could be very useful in some situations, but the benefits do not out weigh the headache and overhead of storing blocks of pixels and writing them to the texture via CPU and transferring data to the GPU at runtime.
I have opted to take Supernat's suggestion of creating a second camera and using a shared transparent material on quads assigned to a custom GUILayer and moving them via transform.
Thanks for all the suggestions
