Slow first time draw of textures

I have encountered a kind of wierd issue with using OpenGL. I am using it in a 2d sprites based setting (see http://users.bigpond.net.au/rz/Scoobie). I find that when drawing a sprite on the screen, the first time each of its frames is drawn is really slow, but thereafter everything runs at a normal speed.

I would not be surprised to hear that this is something to do with my graphics card (an ATI Mobility with 8Mb tex mem only). It is like the opengl implementation on os x is not actually loading my textures into textures memory when I ask it too, but perhaps only into ram. And then it loads the sprite frame into texture memory as they get called upon.

Needless to say, it is completely annoying and I don't see what the point is. Of course, my diagnosis might not be right. The other thing I noticed is how it takes some time to quit the program which I assume has something to do with freeing the textures which were being used. If on the other hand, the sprite does not ever change frames, (ie its other textures are not ever drawn), then the quit happens almost instantly. Wierd, huh?

I am interested to know if this is a problem other people have heard of and encountered. Can someone tell me what the cause is? Or, more importantly, how I can counteract it, so the game runs and draws smoothly straight off the mark?

With regards to my graphics card and texture memory, i know that my 8Mb is enough to hold all the textures I am using in my application. Altogether they would not quite use up all of the texture memory. So, in principal at least, I don't think this issue should be occuring.

DoG Wrote:Remember that the framebuffers also take up VRAM, so you probably have to count 8MB - screenbuffer - framebuffers = VRAM left for textures.

It still should be under the 8 Mb. The textures used take up less than 4.25 Mb in total. And for the screenbuffer it is 640*480*2 / 1024 = 600 Kb. By framebuffer, do you mean the back buffer? This of course would be the same 600 Kb. So, in total we need: 5.45 Mb (at most).

I'm thinking it may have to do with having many textures loaded, in terms of numbers of textures, instead of size. There would be about 720 being used for the animation.

your texture's image will only be loaded into VRAM the first time it's drawn. If you have too many textures for your VRAM it may get paged out again later, in which case you have to draw it again to get it back again. Those times that it's loaded into VRAM will be very slow.

Games like Q3A draw a frame with all the textures for the level, that never gets swapped to the front. You can occasionally cause Q3A to display this frame, though I'm not sure how -- perhaps someone else can chip in here? Basically it's just lots of little squares all over the screen with all the textures on them. This way, if all the textures fit in VRAM, all the delays are during level loading.

OneSadCookie Wrote:Games like Q3A draw a frame with all the textures for the level, that never gets swapped to the front. You can occasionally cause Q3A to display this frame, though I'm not sure how -- perhaps someone else can chip in here? Basically it's just lots of little squares all over the screen with all the textures on them. This way, if all the textures fit in VRAM, all the delays are during level loading.

Ah, this is very interesting, and more or less exactly what I thought was the case. So, it isn't to do just with my cheap old graphics card then. Now I know, I can try and solve the problem by rendering each of the textures to the backbuffer once off before starting the game.