Thus spake "Jeff George": > VASSAL is definitely slower to restore than other apps when I leave it idle > and then go back to it. I have another machine with 1 GB of RAM that I can > try and see if I get a performance difference. I just didn't think that > VASSAL modules would be that resource intensive. > > Regards, > Jeff George
A more appropriate comparison would be between VASSAL and another app which is using the same amount of RAM as VASSAL. I have 512MB myself and I see a lot of swapping when I switching from VASSAL to my browser and back if I have a large module loaded. I predict that you'll have much faster restore times on your machine with 1GB of RAM. Some background: If you look at VASSAL in a memory profiler, you'll see that the images for the maps and the images for the tokens together consume more than 95% of the RAM that VASSAL uses. Images, when stored in memory, are stored uncompressed. This isn't a design choice on our part, rather it's how Java (and virtually every other toolkit which handles images to be displayed on-screen) does it, because storing the images compressed in memory is just too slow. Reducing the number of colors in images doesn't help, since every n by m image still has n*m pixels. I don't think that anyone wants to reduce the dimensions of their images in order to save RAM. So, the upshot of this is that even if we were optimally efficient in our memory usage elsewhere in VASSAL, no one would even notice because the biggest improvement we could get that way would be 5-10%. Something which would make a difference in memory usage is tiling map images when we zoom. The idea here is that when you zoom a map, there's no point in calculating and storing the parts of the map which are off-screen, since you can't see them right now and might not scroll over them at all. Presently, we scale and store the entire map when you hit the zoom button, which results in some pretty extravagant memory usage if you zoom a large map. (I'm working on this at present.) -- J.
