Which reminds me of something else Joel. The “Center on Opponent’s Moves” does not center the moving piece on the screen, it only moves the view just enough to capture your opponent’s move near the edge. You can see this by zooming all the way in, then stepping through a logfile.
This may be by design but it looks more like a bug to me!
OK, I’ve attached a performance test rundown.
For all of these my desktop resolution was set to 1024x768. All were done using version 0.15 of the Case Blue module.
Open: Open the Uranus & Mars scenario and wait until the map is completely drawn.
Zoom In: Once the map has been drawn, hit the zoom-in button once and time until the map is completely drawn.
Jump Map: Hit the Jump Map button and wait until the jump map is entirely drawn.
Quick Scroll: Do step #1 then quickly move the right scroll bar to the top and time the re-draw.
Thus spake “bsmith”:
Did this work before?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yes, this has been around for a while Joel.
Thus spake “bsmith”:
Your results for “Open” and “Jump Map” are exactly what I expected.
Opening a scenario will result in at least one Board being loaded,
which in turn means that a large image is being loaded. It takes
longer to set up a memory-mapped raster than it does one in RAM.
When you bring up the overview map, that results in all of the
Boards being loaded.
I agree, it might have. What did it do?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
That’s by design. It used to center on the piece being moved, but when you’re watching a number of pieces move that are all in the same region, it was disorienting to skip to having different pieces at the center while the map kind of jumped around.
rk
Post generated using Mail2Forum (mail2forum.com)
That makes sense Rodney, thanks.
I can now say more accurately why this doesn’t work: The upper left corner
of the Rectangle returned by Map.getView().getVisibleRect() is rubbish.
It’s not anywhere close to what it should be. Now for figuring out why…
Got it. The MapView needs to have its bounds reset and be revalidated before
we try to move it around, otherwise the numbers produced by getVisibleRect()
are nonsense (though sometimes near enough to be passable).
I think this fixes the bug:
nomic.net/~uckelman/tmp/vass … vn2853.zip
BTW, you’ll also find in this build the work I did on letting the user specify heap
sizes from within the Preferences. (These changes are detailed here:
vassalengine.org/forums/viewtopic.php?p=895#895
I assume that no one has looked at this yet, since I got no replies.) I’d like to
know what people think of this—if you find it to be a good solution or not.
Actually I did see it in the first build you put it in, just didn’t comment
as I saw nothing wrong with this 
I like that its in the preferences and easy to set
Post generated using Mail2Forum (mail2forum.com)
Joel I used build 2850 to generate the performance figures, was that OK? The heap-size preference settings are awesome, worked a treat.
By the way, in light of my testing with Case Blue, should we have memory mapping turned on or off by default?
OK Joel, I tested the Map zoom and it’s much, much better.
There is one thing it needs to do however; When zoomed all the way out such that the edge/s of the map are smaller than the view window. Given Vassal maps always snap to the top-left, when you zoom in it should be zooming to the center of the map boundaries, not the view window. If the map was floating such that the same hex was always in the center when you zoom miles out out, this wouldn’t be a problem. But that’s not the way Vassal behaves. Am I making any sense here?
A better solution would be to make the map float but I’m not sure how difficult this is. I’ve attached two images in the hope this helps explain the problem better. For example’s sake, let’s assumed we were zoomed in on the “CASE BLUE” text of the map before zooming out.
Here’s what I found, running at 1600x1200, all times in seconds:
[code]
open in overview scroll
-mm/512 8 <1 13 9
-mm/1300 8 <1 8 5
+mm/512 25 <1 24 23
+mm/1300 25 <1 27 23
3.0.17/1300 10 3 7 4[/code]
Observations:
For “overview” and “scroll” with 512MB heap without memory-mapped files, the
operations caused some portion of the on-screen image to be garbage collected
from the cache, which meant that it had to be reloaded before the operation
could complete. If not for this, the times for this and for 1300MB without
memory mapped images would have been the same on my system.
When any on-screen image is garbage collected, that means that heap space
is extremely tight. Images are uncached based on how recently they’ve been
retrieved. On-screen images are among the most recently retrieved since
they’re being painted whenever the map refreshes, so if on-screen images
are being uncahced then you’re going to experience a lot of uncaching and
reloading as you use VASSAL. For me, 512MB heap without memory-mapped
images is intollerable to use.
It appears that zooming is completely different for me than it is for you.
If not for the fact that your description of the test is unambigous, I’d
think that we didn’t do the same thing. Now you can see why I was confused
by your reports that zooming was slow.
All of these tests measure one-time costs. For example, once you’ve brought
up the overview map the first time, it will come up instantly thereafter.
If this is indeed the case then my first guess as to the cause would be something to do with a difference between the JVM on Linux and Windows.
Just to re-cap… I open the module, wait for the map to completely appear; I then hit the “+” zoom button once while simultaneously starting the timer. I stop the timer when the entire map image has filled the view window.
Joel do you have a Windows box handy to test this yourself?
One-time costs are fine for Live play when you keep a game open for hours; But for PBEM where the load times are more important it’s not so good. In fact an opponent recently told me my Tunisia Vassal module may have a problem because it took 15 seconds to open!
Thus spake “bsmith”:
Yes, that’s how I understood it as well.
I do. I’ll try it in a bit.
I usually do something else for a moment after loading a large module—I
check my mail, make some tea, or play with my cat. I don’t find times
under 30 seconds to be onerous for an app which I’m going to use for a
half hour or more.
Yesterday I did some profiling to find out where the load time is being
spent. 70% of it is in the method in my MappedDataBufferByte class called
by ImageIO to set pixels as they’re decoded. That method has two lines,
one of which is a bounds check and contributes negligibly to the runtime,
and the other of which is a call to a method in the JDK API—so nothing
I can do there to speed up loading. Making the method final, removing the
bounds checking, and collecting calls to the method to write more data to
the DataBuffer in one go all make no difference that I can see.
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “bsmith”:
On my wife’s Windows XP system (512MB RAM, Athlon XP 2000, 1280x1024 screen
resolution) if I load Case Blue with 512MB heap and memory-mapped files
on, first-time zooming takes about 3 seconds to complete.
I think the difference is not in the JVM. Maybe memory-mapped files are
broken on Vista?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I know what the problem is Joel, you must be using a version later than build 2850. Remember you changed the zoom behavior so now it’s zooming into a section of the map which has already been loaded
Thus spake “bsmith”:
If you’re zooming in right after loading the scenario, you’re in the
upper-left corner of the map. Zooming in there works the same now as
it did before. Nice try, but I think that’s not the explanation.
If you use 2866, do you still have slow zooming?
nomic.net/~uckelman/tmp/vass … vn2866.zip
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I’ll try that in a sec. When I use 2853, zooming is fast. When I use 2850, it’s slow. I’ll attach some screenshots in a tic.
Ahhh crap, I just thought of something else. My preferences will be different to yours. When I open the scenario, I’m scrolled to the bottom-right of the map.