FrameBuffer.blit(RGBColor...)

[Thomas.]

Please, could you add method FrameBuffer.blit(RGBColor col, int destX, int destY, int width, int height, boolean transparent)? This should be much faster than blit 8*8 white texture with additional color.

[EgonOlsen]

Why should that be any faster? It's the same basic operation of rendering a quad...

[Thomas.]

I suppose, when is blitted texture with additional color, to every pixel of texture is added additional color, so on 1280*720 it is a lot of extra calculations... But I do not know what is hiding in the background.

[EgonOlsen]

On PowerVR this has no effect at all. On Mali and Tegra it's faster if you omit the texture and render the color only, but that's only noticable in a very artifical test case when you blit 100 times the same texture filling the whole screen. And why would you want to do that? A clear with some color would be much faster anyway...

[Thomas.]

It is for menu. Everything are blitted with using colors, there are not needed any textures. How big differences are in speed?

[EgonOlsen]

When filling the screen (1280*800) on the Nexus 7 100times, it's half as fast when using the texture access then without it. But as said, that's a stupid test case. Nobody would do that and no menu would come even close to these numbers...

[Thomas.]

Well, so I try optimize my code sometime in the future (fps drops down from 60 to 55 when is editor menu visible)... Thank you for testing

[EgonOlsen]

If it ever becomes a problem, i can still try to detect your special case and optimize the shader for it, but i don't think that this will ever be needed. The drop you see comes from the additional rendering and state switches and such, not from the lack if fill rate.