What needs t o be resolved before 3.2.0?

I think I’ve finally isolated this issue.

If I scroll around, zoom in and out, until the java.exe has consumed it’s entire heap allocation, then I set the zoom level to 100% or higher (maybe this is related to the size of a tile vs the size of the visible image?) and set the map window to straddle the boundary between two large map images such that a portion of each map is visible, the tiles never stop re-painting themselves causing the map image tiles to blink and flash endlessly (and occasionally, after a while, throw an exception/eek bug). If I reduce the image size to less than 100% (75% in my case) and/or move the window off the map boundary, the flashing/blinking stops and the map repaints itself correctly and only once (at least that I can see).

I can reproduce the blinking-symptom at will now that I know root mechanism.

(The issue can probably be reproduced separately, but just in case I’ve posted the module that I used to cause the issue here: dl.dropbox.com/u/24119799/WAA.zip
It’s 83 MB, just FYI. Run it in v3.2 and set up at least two of the six map segments to reproduce the issue.)

-Mark R.

Thus spake mroyer:

“mroyer” wrote:

I still think there’s a memory-leak problem in 3.2 related to
unloading image tiles and with large modules eventually causes
problems.

I think I’ve finally isolated this issue.

If I scroll around, zoom in and out, until the java.exe has consumed
it’s entire heap allocation, then I set the zoom level to 100% or higher
(maybe this is related to the size of a tile vs the size of the visible
image?) and set the map window to straddle the boundary between two
large map images such that a portion of each map is visible, the tiles
never stop re-painting themselves causing the map image tiles to blink
and flash endlessly (and occasionally, after a while, throw an
exception/eek bug). If I reduce the image size to less than 100% (75%
in my case) and/or move the window off the map boundary, the
flashing/blinking stops and the map repaints itself correctly and only
once (at least that I can see).

To what do you have your max heap set?

The most likely reason this is happening is that the image cache is being
cleared before what’s on your screen is finished painting, which triggers
reloading those same images during the next repaint cycle, which again
causes the cache to clear partway through.


J.

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.

-Mark R.

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:

vassalengine.org/~uckelman/builds/

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


J.

Thanks. But, even more, thank YOU for figuring this all out!
I’ll give the new build a go - perhaps this evening.

I knew the huge maps would push on corner cases, so I’m glad they were part of the v3.2 beta testing.

-Mark R.

Gave it a quick go… feelin’ sweet! No evidence of the old problem at all. More, the repaint seems generally snappier - is that possible or just wishful thinking on my part?

-Mark R.

Thus spake mroyer:

Gave it a quick go… feelin’ sweet! No evidence of the old problem at
all. More, the repaint seems generally snappier - is that possible or
just wishful thinking on my part?

Repaint at 1:1 is definitely swifter, since it’s using the tile cache
now, whereas it inadvertantly wasn’t before.


J.

Just thought I’d pass along the following sent to me today from one of my module play-testers regarding the most recent VASSAL build.

-Mark R.