Hey all,

This is my first time posting, but I am a fairly experienced OpenGL programmer.
I am building a 3d engine for commercial release, so I cannot reveal any source code... But
I am having a problem with a strange slowdown that occurs seemingly from calling glBindTexture.

As far as all of my past experience has taught me glBindTexture is simply a reference reassignment,
it shouldn't take much processor at all, but after I call 5 bindtextures for different objects, each binding
a png which is loaded with internal format as a Palette4_RGB8 that is 1024x1024, the entire program
starts to chug heavily. Before that, 4 bind calls for instance, no chugging, no lag.

I know the textures are fairly large but they are 16 color compressed bmps so shouldn't be that much of a strain.
Oddly enough it was the same number of bind commands that caused slowdown when I was loading them as full color quality RGBAs! Now I might not know everything about openGL, I'm certainly no expert, but this seems extremely wonky to me... Is there some kind of known hardware problem about a limit to the texture size able to be passed through bindTexture commands?

If anyone at all can shed some light on this mystery for me it would be extremely appreciated. I can squeeze a few more square pixels out of the system by binding smaller, 256x256, images per call, but not enough to try and compartmentalize the textures or lower their overall resolution. it seems like you can only bind a certain number of pixels to active textures per tick, regardless of memory size, before the buss overflows or you start paging to disk or whatever it is...

Sorry for ranting, I have been trying to fix this problem for 18 hours now and am quite frustrated. Thanks in advance for any help.

This sort of stuff varies a bit from system to system I think.
When coding for iPhone I found that reading the documents that Imagination had for best practices was really helpfull (the people who designed the gpu of the iPhone).

What may be the case, I suspect, is that the texture cache is trashed.

I'm quite new with android development, so I don't know, is there a opengl profiler for the system?
It would probably give you a lot of answers as to why you're seeing performance hits.

I'm about to start a thread here about Opengl on android best practices. Hopefully we can get a lot of good tips and tricks into that thread.

This just an update on the issue.

I discovered that the compression system in android, or possibly just the g1, is apparently faulty.

Loading in a texture with palette compression does not reduce the amount of video memory
that the texture takes up even though it should.

I have a feeling this is an problem with androids implementation of the compressed texture functions.

If anyone has any advice on how to get paletted textures to load and stay as such in video memory
I would be quite grateful.

Currently my textures are taking up full bitmap size whether compressed or not, and that caused slowdown
when the VRam overflowed and bind had to shuffle memory into and from Ram.