Very slow pixel-conversion inside glTexture2D (texture.c) for Big-Endian.


Hi ptitSeb!

As you may noticed in close Irrlicht Engine issue, i found out that something very weird happens when we load textures.
And does not matter if textures are 3MB of size, or just 10KB of size , it always the same constant slow. 

We with Daniel spend some hours on debuging and find out, that when we call glTexImage2D() with something like 8-8-8-8-REV or even 1-5-5-5-REV, the speed of loading textures 
drops in factor of 5. When we use something which have no need conversion, like GL_UNSIGNED_BYTE, then it's fast.

By massive. speed drop i mean : GL_UNSIGNED_BYTE 0.5 second for 10kb texture, and GL_UNSIGNED_8_8_8_8_REV for the same 10kb texture takes 3 (!) seconds. Imagine when we load 30 textures, the
difference.

Next, we just grab latest GL4ES, and replace in texture.c all big_endian ifdefs on crap, so to not call conversion, and the same test code with 8_8_8_8_REV start to be very fast as expected.

Now, we have a wild guess that this is probabaly due to the heap activity (malloc/free). That just a guess, but probabaly we can solve it by one of those solutions:

1). create and use a big (eventually growing) per-context scratch-buffer for stuff like that.
2). for smaller temporary buffers, use dynamic alloc on the stack.

At least we think that such a massive slow down and that does not matter size of the textures at all, can be caused due to the heap activity. And currently we have no needs to check other types,
as 8_8_8_8_REV is one which already dead slow and we can test with.

Of course, i will be gladly donate for a solution with no problems. And other PPC machines will benefits too :) 

Thanks !