svg map slow--which changes to make?

I’m working on a module with a board having 64 rows of 60 hexes each. I tried replacing the png map with an svg map,
but VASSAL runs too slowly with it. It might be 100* slower or so. I tried loading it for a game, and editing the hex grid–both
were on track to take 30 minutes or so to load the map, so I stopped the runs.
Which of these changes are worth experimenting with?

  1. Convert the svg map to png
  2. Make the svg less redundant and less wordy–I might be able to cut it down to 1/3 size or so.
  3. Don’t provide the hex grid as part of the svg–maybe VASSAL is faster using only its own hex grid?
  4. Don’t provide the grid coordinates as part of the svg–maybe VASSAL is faster using only its own coordinate marking?

Board 64X60 hexes, 2MB svg, 11MB old png, 3.25MB new png.
svg created directly by a perl script
old png is a pasteup of John Cooper’s art and board extensions created in postscript by a perl script and converted to png.
Proposed new png–converted from the svg.
The module prior to these changes is at:

dropbox.com/s/lkjn1b3l38fgg … .vmod?dl=0
Thanks
Stewart

I think it was Brent who earlier said map pixel size was more important than file size.

What’s your map size in pixels?

The svg and new png are 3575x3904 pixels (13956800 pixels). The old png is 3800x3900 pixels (14820000 pixels).
I tried the new png in the module and it edits and plays at a normal(?) speed. It might be about the same speed as the old png.
Thanks
Stewart

Here’s an svg of a piece of the board. I had to rename it to text to avoid an error message–the forum software said
it couldn’t determine the dimensions of the image. VASSAL has no trouble with the full-sized image. I think all my svgs start the same way, copied from Uckelman’s “The Longest Day” svgs.
Thanks.
Stewart

Thus spake scs:

dropbox.com/s/lkjn1b3l38fgg[1] … .vmod?dl=0
Thanks
Stewart

This link doesn’t work.

J.

Somehow I lost a “jc” on the end of the URL.
dropbox.com/s/lkjn1b3l38fggjc
has the old png

The new svg is
dropbox.com/s/eo54g3i0ca2im … 4.svg?dl=0

Thanks
Stewart

My svg map slowness might be an operating system issue rather than VASSAL. I’m having slow response when displaying svg files outside VASSAL, using utilities like eog/eom, gthumb, the imageMagick utility “display”, etc.

Response is much faster on my Linux Mint 17.1 machine (which isn’t set up completely yet) than on my Ubuntu 12.04 machine that I normally use. Most other programs run at similar speeds.

Thanks
Stewart
sstrait1@san.rr.com

I probably have 2 problems–very slow tiling (not dependent on linux version) and some sort of rendering problem (dependent on linux version and affects things outside of VASSAL) I’ll try to post again after I’m more organized and have tried everything with VASSAL 3.2.17. I’m conjecturing _without_knowing_the_VASSAL_code that tiling SVG files is O(n squared) in the size of the board. (Maybe makes a whole pass thru the SVG file for each tile, so if you have a file k times bigger, it makes k times as many tiles, taking k times longer per tile). Again–this is mere conjecture.

Thus spake scs:

I probably have 2 problems–very slow tiling (not dependent on linux
version) and some sort of rendering problem (dependent on linux version
and affects things outside of VASSAL) I’ll try to post again after I’m
more organized and have tried everything with VASSAL 3.2.17.

I’m
conjecturing _without_knowing_the_VASSAL_code that tiling SVG files is
O(n squared) in the size of the board. (Maybe makes a whole pass thru
the SVG file for each tile, so if you have a file k times bigger, it
makes k times as many tiles, taking k times longer per tile).
Again–this is mere conjecture.

That’s not how rendering tiles works. We render each image once when
tiling, then make all tiles at all sizes from it. Enlarging the image
will make more tiles, but the image is still rendered only once.


J.

Very reassuring that my notion of the logic was wrong. I’ll still check timings, but without any particular theories in mind. In particular, I may have a non-VASSAL problem that slows many large SVG file operations. I do no graphics outside of VASSAL, web browsing, and some trivial photo processing, so VASSAL is where I’m likely to see all my problems. I presume that since I’m seeing a lot of little rectangles of the board coming and going when I try to start up that VASSAL is doing the tiling then.
Thanks
Stewart

Thus spake scs:

Very reassuring that my notion of the logic was wrong. I’ll still check
timings, but without any particular theories in mind. In particular, I
may have a non-VASSAL problem that slows many large SVG file operations.
I do no graphics outside of VASSAL, web browsing, and some trivial
photo processing, so VASSAL is where I’m likely to see all my problems.
I presume that since I’m seeing a lot of little rectangles of the board
coming and going when I try to start up that VASSAL is doing the tiling
then.

Tiling happens the first time you open a module. If you’re seeing
tiles blink out to gray and then reload, you’re running with too
little max heap.


J.

The blinking out etc is what I’m seeing. Am experimenting with max heap, but it hasn’t helped so far. Where should I see an error message if my max heap is too big?
Thanks very much.

Thus spake scs:

The blinking out etc is what I’m seeing. Am experimenting with max heap,
but it hasn’t helped so far. Where should I see an error message if my
max heap is too big?
Thanks very much.

There would be a dialog telling you so. To what do you have your max
heap set? How much RAM does your machine have?


J.

I just set the max heap to 768 MB (960 MB for the other size). It did not help.
The default was 256/512.

I have never seen the heapsize dialog, even if I ask for max heap=8192 m .
I presume I have 1 GB of memory,
since cat /proc/meminfo says
MemTotal: 1015900 kB
and free -m says
992 under “total”

dropbox.com/s/awj6rtmw7nyz85y
is the offending module.
dropbox.com/s/s4jgu2evy3560g0
is the same module except the board is a png–works fine.

You can attempt to play the offending module, but it takes minutes to repaint when you
scroll around. It shows red hexsides on white sometimes when repainting.

The module seems to never tile. It does not show a tiling popup and if you delete all the recent tile cache it does not recreate it.
The png module does show the tiling popup and does recreate its cache.

I’m sure I’ve given too much information, but better than too little.
Thanks
Stewart

Hi Joel, Stewart,

I have just had a quick play with the module and I can confirm that Vassal does not appear to be handling the svg version of the map correctly. It does not attempt to tile the image before play. It appears to be re-rendering the image on-the-fly as required.

This is because you have asked Vassal to paint the hexes in red. Turn off the ‘Show Hex Grid’ option.

Brent.

Thus spake Brent Easton:

Hi Joel, Stewart,

I have just had a quick play with the module and I can confirm that
Vassal does not appear to be handling the svg version of the map
correctly. It does not attempt to tile the image before play. It appears
to be re-rendering the image on-the-fly as required.

I see that’s what’s happening, now that I’ve had a closer look. I
should have time to look into this in the next few days.


J.

Thanks for looking into this. I’ll use a png board for the time being. I noticed that the module is 273k with svg and 3211k with png. The svg looks better when you zoom in, too. For these reasons I’ll switch back if there’s a fix. Sorry for being somewhat ill-informed and disorganized when reporting this.

If anyone is using Linux and wants to convert some other module (and has imageMagick installed) all you need to do to make this kind of change is, I think:

  1. unzip the vmod into its own subdirectory
  2. run the command: convert {boardfile}.svg {boardfile}.png
  3. remove the svg from the subdirectory.
  4. Edit the buildFile to use the new boardfile name.
  5. zip the vmod, probably giving it a different name.

The same sort of process should let you do other conversions or substitute other boards. My experience is very limited, but I think this isn’t a very tricky way to edit a buildFile.

Thanks again
Stewart