Large Amount of Memory Used Drawing Photos
BlitzMax Forums/BlitzMax Programming/Large Amount of Memory Used Drawing Photos
| ||
| Hi, I'm making an app at the moment that includes a basic slideshow feature that loads up JPEGs from a specified directory and plays them at a configurable interval with a basic fade effect in between. The JPEGs are obviously scaled to fit onto the window, and are being drawn onto a MaxGUI canvas. The problem I'm having is that when I load the images (there's about 8 150KB JPEGs with resolution of about 1024x768), it seems to consume a lot of memory in Task Manager (about 40MB is added) and then, as the images are drawn one after the other, memory increases further by about 8MB each time until all the pictures have been shown once and are looping through again, at which points it remains constant (at about 100MB!). Surely this isn't normal, I'm not doing any fancy affects - it is literally drawing and scaling the image to the screen and I can't expect customers to be using almost 100MB of memory just for a small app. In addition, I've tried loading BMPs, PNGs and every single other format I could think of and it makes no difference. Finally, I also tried using the Image Loader sample app that comes with BlitzMax, and loading the same images and it still eats loads of memory! What can I do to make the memory usage reasonable? Has anyone else experienced this? Is BlitzMax just not designed to handle large images (instead of miniature game figures)? Many thanks Seb P.S. I'm on Windows Vista but I've tried the same program on Windows XP and it doesn't seem to make a difference. |
| ||
| A 1024x768 image will take up roughly 4mb. So if you have 'about 8' of them, that's 'about' 32MB. GCMemAlloced() doesn't show resources used by those images until they've been drawn for the first time, hence the gradual increase. How can you make the memory usage more reasonable? Don't load eight massive images at once. |
| ||
| It doesn't matter what file format the images are, as they will all get uncompressed when loaded into memory, which is why your 150KB file turns into about 4MB, as Gfk has pointed out. If you want to limit the amount of memory that is being used, then you will need to load them off disk when needed and then purged from memory when no longer needed. Basically, only keep 2 images in memory at once - the current one (for display and use within your fade), and the next one. Once the next one is fully visible, null the last one (so it's freed from memory), and load the next one in ready for the transition. I would also use a GCCollect() call after freeing up the first picture to free the memory straight away. |
| ||
| Basically, only keep 2 images in memory at once - the current one (for display and use within your fade), and the next one. Once the next one is fully visible, null the last one (so it's freed from memory), and load the next one in ready for the transition. I did this in my current game using a tList.If I want to fade to a new image, I load a new one and add it with 'tList.AddLast object'. An object would just contain a tImage field, and an alpha float. I know that if there are two items in the list, then I'm supposed to be fading the last one in (newest), and the first one out (oldest). When the alpha of the first one reaches 0, I remove it from the list. When the object and therefore the tImage go out of scope, GC cleans it up. Rinse, repeat. |
| ||
| Did as suggested and the HDD lag isn't really that noticable - I'd have thought all the images into memory would be necessary for acceptable results but it loads really quickly and is tonnes better memory wise. Thanks for the tips everyone! |
| ||
| <useless fact> Platypus loaded its graphics "on the fly". </useless fact> |
   |