When I open a large map image (c 15 Mbytes) and zoom it beta 5 can take several minutes to display the image. Each piece (or two pieces - seem to appear in pairs) appear at intervals of several seconds or minutes even. But very strange occurrence. I have an old version of the module with the same map which works fine (built under beta1) and the latest version (built under beta4) which performs horribly
Setting preferences to prefer memory mapped files seems to get rid of this problem.
Looking at my CPU monitor I get a single burst of 80-100% cpu usage with memory mapped files and a very long time with all four CPUs running at approximately 30%!!
Using the debugger I can see two pool threads running the image zooms and they seem to be thrashing (they are both continually locking the data buffer they are extracting the data from).
When I tried loading the case blue OCS game I had to kill it eventually as it was hogging my whole machine (64 bit linux on quad core 3GHz processor with 8Gbytes memory) after about 10 minutes
Turning on memory mapped images meant this game came up in 10-20 seconds
If using memory mapped files helps, then most likely what’s happening when
you’re not using them is that you’re hitting the heap ceiling frequently,
which causes the image cache to clear in order to get sufficient memory
for carrying out some operation. Among the images dumped from the cache
could be your large map image, which then needs to be reloaded next time
the map is painted to your screen.
This what I’d expect for decoding a 15MB image.
Locking? What do you mean by locking, exactly? The scaler doesn’t do any
synchronization or locking itself, and doesn’t call any API methods which
are declared to be synchronized.
This may be a 64-bit java on 64-bit linux implementation problem.
Tried “new game” with multiple possible maps and waited for map to appear in selection window I made the initial heap size 1Gbyte and the maximum 3Gbyte and this had no effect. Further investigation has shown that all the time is being used on one line:
GeneralFilter.java: 281
final Raster srcR = srcI.getData(new Rectangle(sx0, sy0, sw, sh));
at zoom .2 it’s getting an image approximately 1300X1300 to scale it
Putting a break on this line and the next I found
With mapped image files this take zero time. Without it takes 70 seconds!! At lesser zooms the time is reduced - approximately proportionate to the size of the data being fetched.
This is definitely a problem with buffered images since it all worked without a hitch in beta4
Once it has been done I can zoom the map to the same leveland everything is instantaneous bot to a different level and then it dies again.
I also transferred everything to my laptop and there all was fine.
Is there anyway I can make memory mapped images the default for all modules I play. I can clearly set it by using edit Module to get into the module preferences without loading a map but if I forget it’s going to be a nuisance
My heap size was set to 3GB. But changing the size had no effect. Breaking in with the debugger always shows it deep within the native code accessing the X-window where the data is buffered.
I’m running jdk 1.6 update 10 - the latest version from sun’s website.
The only difference is I created the .PNG images files with different software (which rediced the size from 16Mb to 13MB)
THIS is the problem!!! Using the 16MB image and everything works fine!!!
Something strange in the smaller .PNG image? Ok It fixes my problem - just have to use the bigger file
Nothing to do with VASSAL, just the buffered images uncovered the problem. Sorry.
It’s a buffered image and it seems to be holding in an X-windows buffer. At least it’s using X window calls to retrieve the data when stopped with the debugger.
The working one was created on windows using windows calls to convert a bmp image in memory to a .PNG file. The non-working one was created on linux64 using image-magick library to do the same thing. (Just a port of the program from windows to linux)
Well, the internal format of the two files is different. The smaller one is smaller because there isn’t an alpha channel. I haven’t looked at all into what this is slower in VASSAL.
The offending image is loadable without incident by every program I’ve
tried (eog, gimp), and since you say that it was created by ImageMagick
I’m inclined to think that it’s a standard-compliant PNG.
As a test, I created a new module containing two boards, one using each
of the two images. In both cases, I counted 2-3 seconds before the map
image appeared in the board picker after choosing it from the drop-down
box. I did this with both Sun’s 1.6.0.10 and OpenJDK 1.6.0-b09 with the
same results. My system is Linux (Fedora) and also 64-bit, so is
superficially pretty similar to yours.
Do you know what window manager/desktop environment you’re using?
(Possible answers would be Gnome, KDE, XFCE, among others.)
Could you try the problematic image with a build newer than beta5, and
let me know if you still see the same problems? (You can find such builds
here: nomic.net/~uckelman/tmp/vassal/)
I tried the latest build in your list and still had the same problems. I don’t get the problem on vista32, vista64 or 32 bit linux, only on my 64-bit linux. If I open and save the image with GIMP I don’t get the problem (although the image is 3 mBytes bigger)
So I can work around the problem which is definitley somewhere in the java/linux/X-windows interaction rather than a VASSAL specific problem.
If you have Compiz enabled but too little video RAM, then it’s possible
that you’d end up with odd artifacts when running VASSAL. That’s what I
suspected to be the problem.
I don’t know what the setting is called in Ubuntu, as they name some
things differently from Fedora.
I’m using two NVidia GeForce 8800 Ultras with 768 MByte of video ram each driving a different screen. So it’s not a low video memory problem ( I hope )
)