Slow first time draw of textures

rzilibowitz
Unregistered
 
Post: #1
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.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #2
Remember that the framebuffers also take up VRAM, so you probably have to count 8MB - screenbuffer - framebuffers = VRAM left for textures.
Quote this message in a reply
rzilibowitz
Unregistered
 
Post: #3
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
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.
Quote this message in a reply
rzilibowitz
Unregistered
 
Post: #5
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Occlusion queries... SLOW. TomorrowPlusX 8 4,569 Aug 19, 2005 07:05 AM
Last Post: TomorrowPlusX
  Are SDL events slow? Skorche 3 4,276 Jul 25, 2005 11:08 AM
Last Post: Skorche
  SDL got pretty slow on Tiger? Zeeke 17 8,809 Jun 5, 2005 12:29 AM
Last Post: Kevin Lindeman
  This thing = way too slow LongJumper 9 4,713 Dec 20, 2004 05:14 AM
Last Post: TomorrowPlusX
  Terribly slow :-( CMagicPoker 7 5,260 Jun 23, 2002 04:06 AM
Last Post: CMagicPoker