   textures cause large jump in used memory -- why?
  Greetings.  I'm writing an application using JOGL, and I load 4 separate textures at initialization.  The sizes of these textures are:  518 KB236 KB243 KB215 KBHowever, the additional memory my application uses after these textures are loaded is 35MB (65,000K before the textures are loaded, and 100,000K afterwards).Why is this?   
  Are the images compressed? (JPEG, PNG, GIF, etc.)   ;  Yes, they are compressed.  Now I understand.  Are there any tips to lowering the memory used by textures, or is that just a fact of life?   ;Quote:Original post by slikrikYes, they are compressed.  Now I understand.  Are there any tips to lowering the memory used by textures, or is that just a fact of life?You mean like... using Texture Compression ? ;)Check S3TC (S3 Texture Compression), also known as DXTC (yes MS like to rename thing as if they are their own).   ;  If those are the sizes of your textures then thats nothing for VRAM to hold, even with mipmapping 512kb isn't much. I got 3meg textures in my 64MB videocard and have no problems. I don't think texture compression will help much with texture sizes that are so small, but I could be wrong...   ;  and you are mars. I can compress a picture into jpg/gif at 10KB which results in a 6mb image loaded.Firstly DirectX will load your textures as RGBA - 8, thats 8 bits per colour, if ur having trouble u can turn it down to 4 bits per colour how ever this will only half the memory used.How large are the pictures, what are there dimensions?You shouldnt load anything larger than 2048x2048 i mean that will eat ram and GPU   ;Quote:Original post by dawidjoubertand you are mars. I can compress a picture into jpg/gif at 10KB which results in a 6mb image loaded.Firstly DirectX will load your textures as RGBA - 8, thats 8 bits per colour, if ur having trouble u can turn it down to 4 bits per colour how ever this will only half the memory used.How large are the pictures, what are there dimensions?You shouldnt load anything larger than 2048x2048 i mean that will eat ram and GPUHow is that possible... 10kb couldn't make 6megs e.g. 128x128x4 = 65k now add in 64x64, 32x32, ect down to 1x1 and you might get 256k but not 6MBs for textures.   ;  The sizes he is quoting for his textures are compressed, not thier uncompressed sizes - thus you can't do the old width*height*pixeldepth to work out the number of byte for the size of an image.For example if the textures are a solid colour (this is just an example) - then will compress extreamly well but when it hits the graphics card it will be uncompressed, unless you use the extersions that Ingenu mentioned.GOCPSide note , adding mip-mapping makes things 4/3 the size that they once were, does it not? (it's early so my mind is fuzzy) - a 65k image couldn't grow to 256kb with mipmapping.   ;  when mipmaping you only add 1/3 of the size to the orignal image, so a 65K image would end up at around 86.6K when uncompressed.   ;  One point is that it is your working set that matters, not the virtual memory allocated to your process. The virtual memory is pretty much only good for telling you if you have a memory leak.   