The latest build “VASSAL-3.2.0-svn8249-windows.exe” seems to have an elusive issue with repainting the tiles of a large map to the map window. I can’t isolate it or describe it well, so I mention it mainly in case anyone else is experiencing similar issues.
It is too elusive for me to give much more info (I’ll try to describe the symptoms below) and it could be my computer. However, I didn’t not experience the problem with earlier builds 8221 or 8186 - it seems to have cropped up in the last few days after installing 8249.
Symptoms: I have a very large map in my module and when I scroll to another region, or zoom in or out in the same region, on occasion the map doesn’t repaint, or only partially repaints a few tiles. Usually it repaints quickly (in a second or two) and works fine as expected. But other times it seems to bog down and takes 10 to 20 seconds, and sometimes much, much longer for the repaint to complete. On occasion the repaint never finishes - at least not as long as my patience holds out. One time, various map tiles kept blinking in and out on the screen, endlessly. It seems that once it gets into this state, it stays bogged down for good and I have to close and re-open the module to get it to run snappy again. It feels like some sort of memory leak or overflow issue.
I will continue to try to figure out when it occurs and what triggers it if I can - or if it clears up and turns out to be my computer I will let you know.
The latest build “VASSAL-3.2.0-svn8249-windows.exe” seems to have an
elusive issue with repainting the tiles of a large map to the map
window. I can’t isolate it or describe it well, so I mention it mainly
in case anyone else is experiencing similar issues.
It is too elusive for me to give much more info (I’ll try to describe
the symptoms below) and it could be my computer. However, I didn’t not
experience the problem with earlier builds 8221 or 8186 - it seems to
have cropped up in the last few days after installing 8249.
The only thing which changed in the graphics pipeline on the trunk
between 8221 and 8249 is a bug fix for the boundaries of tiles which
are rotated 180 or 270 degrees. Is your map flipped?
Symptoms: I have a very large map in my module and when I scroll to
another region, or zoom in or out in the same region, on occasion the
map doesn’t repaint, or only partially repaints a few tiles. Usually it
repaints quickly (in a second or two) and works fine as expected. But
other times it seems to bog down and takes 10 to 20 seconds, and
sometimes much, much longer for the repaint to complete. On occasion
the repaint never finishes - at least not as long as my patience holds
out. One time, various map tiles kept blinking in and out on the screen,
endlessly. It seems that once it gets into this state, it stays bogged
down for good and I have to close and re-open the module to get it to
run snappy again. It feels like some sort of memory leak or overflow
issue.
This is what I would expect to see if the tiles which are displayed on
screen come very close to filling your image cache. You might need to
increase your max heap a bit.
Just tested svn8249 with my super-large map. I couldn’t get it to fail to repaint, but if I snap the scroll-bar from one side to the other, it did take a couple seconds for the map to start painting on-screen. Kind of looks like it was spending the time on all the space between where I was and where I moved to.
Haven’t really looked at that before, so I don’t know if that’s actually different than before; I wouldn’t be surprised if its the same. I suppose I’m going to have to try this with a lot of counters pulled and see if it slows down any more…
This is what I would expect to see if the tiles which are displayed on
screen come very close to filling your image cache. You might need to
increase your max heap a bit.
–
J.
I did that - I went from 512 MB to 1024 without effect. Go more?
A while back you suggested I drop it to 512 for other issues
No, 512MB should be enough, unless you have some very, very large
piece images.
As a side note (but totally unrelated to painting large gifs): I have been noticing for a long time that if you open a new game, play a bit, close it, open again, etc etc… then after a while Vassal will become less and less responsive, slowing down to a crawl.
I should mention this is in “edit module” mode, when you add/modify some trait, play test, close, add/modify, play test, close etc etc. But probably happens in normal “open module” mode, too. One has to save and close the module (and quite possibly) restart Vassal afresh.
Appreciate that, but I keep a fairly healthy history of builds on hand just for this type of situation.
I’ll let you know if I need to go further back than I have.
So… after two consecutive evenings of playtest with this issue, last night’s playtest did not have the problem. My map repainted snappily (full screen repaint within a couple seconds) throughout the 2+ hour session. Note: this was on build 8249.
I think I did notice Rindis’s large-jump delay that he referred to earlier in this thread; I tried specifically to reproduce it. But, even that was minor, instead of a typical second to repaint maybe it took 3 seconds.
So, I’m not sure what to conclude beyond I’ll monitoring and see how it goes.
I had chalked this up to something peculiar with my computer, but now it’s back with a vengeance and I have gotten an “Eeek!” bug that might help with some clues. This is with build VASSAL-3.2.0-svn8249-windows.exe.
The “Eeek!” bug occurred when I was in the blinking-tile-never-finish-repaint state and I tried to save the game. When I tried to submit the bug it said it couldn’t and instructed me to submit the attached "errorLog file (had to change the extension to .txt to be allowed to upload). Also, while the very slow repaint (10’s of seconds) occurs anywhere, the endless blinking state has always occurred at a map section boundary between two large map boards.
In addition, after this bug I dropped back to build 8213, which I have been using without a problem for about an hour. Repaints are all snappy (within a second, two max). I am going to continue to use this build for a day or so and if it continues to work well, I will try the latest build (8258), unless you tell me to try something else.
