[messages] [Developers] What needs t o be resolved before 3.2.0?

Joel Uckelman uckelman at nomic.net
Tue Nov 27 08:53:41 MST 2012


Thus spake mroyer:
> I've tried setting the max heap to a bunch of different sizes from time
> to time.  I had it at 512 MB for quite a while. It happens to be set at
> 1024 MB at the moment.
> 

I found the cause of the problem. The ImageOp for the 1.0-scale board
image was getting the wrong path to the board image, which caused the
tile cache lookup to fail. When that happens, we check the images
directory in the module to see if we can find the full image there. (The
reason for doing this is that you might be using the editor and have
just added the image, so it wouldn't yet be tiled.) The cache check
appends "image/" to the image path, while for historic reasons, the
in-module check does not, and takes care of it somewhere else. This a
bad state of affairs, and you found one of the cases where the
inconsistency between the two path conventions causes bad behavior.

What's happening in your case is that we get the the correct tiles for
every scale factor *other* than 1.0. For 1.0, we don't find the tiles,
but we do find your colossal images, and we also know how to tile
images in memory, so we try that, rather than failing outright. So 1.0
scale factor works, but slowly, so long as all the tiles on screen are
from the same image. What happens when you scroll to the boundary
between two images at 1.0 scale factor is that a request goes out to
load the second map image in order to make tiles from it in memory. Your
map images are so large that only one fits in the JVM heap at a time,
so as soon as the second image starts to load, the first one and its
tiles get kicked out of the in-memory image cache. If you don't scroll
away, the next repaint send out a request for the tiles from the first
map, which causes the first map to be reloaded, which kicks the second
map and its tiles out of the cache. This will cycle forever if you let
it.

Try 3.2.0-svn8434, which I believe corrects the problem:

http://www.vassalengine.org/~uckelman/builds/

Thanks for being persistent about this; as you can see, the cause was
rather subtle.

-- 
J.


More information about the messages mailing list