G’day,
I’ve had some reports from players of the Battlelore module that the latest versions of Vassal (3.2 and higher) have made gameplay lag.
I’ve been testing the latest builds of Vassal, right now I’m using 3.2.5 svn 8654 on Windows 7. There is definitely some lag occurring.
The easiest way to test this is to download the module from the following link:
http://www.vassalengine.org/wiki/Module:BattleLore
Start the first scenario - 01 Agincourt.
Pick a side. e.g. “Pennant” player
Then click and drag over a large number of units.
You will see that the selection rectangle stays on screen for a while before all the units get selected. Even selecting only 3 units will see this occur. Then try using the right click menu option “Take Hit”. Once again there is some lag before the pieces update.
When playing the module with Vassal version 3.1.20, there is no lag.
If anyone needs more clarification of the problem, I’ll try and display it more clearly.
Cheers
LB
Thus spake LB:
G’day,
I’ve had some reports from players of the Battlelore module that the
latest versions of Vassal (3.2 and higher) have made gameplay lag.
I’ve been testing the latest builds of Vassal, right now I’m using 3.2.5
svn 8654 on Windows 7. There is definitely some lag occurring.
The easiest way to test this is to download the module from the
following link:
vassalengine.org/wiki/Module:BattleLore
Start the first scenario - 01 Agincourt.
Pick a side. e.g. “Pennant” player
Then click and drag over a large number of units.
You will see that the selection rectangle stays on screen for a while
before all the units get selected. Even selecting only 3 units will see
this occur. Then try using the right click menu option “Take Hit”. Once
again there is some lag before the pieces update.
When playing the module with Vassal version 3.1.20, there is no lag.
If anyone needs more clarification of the problem, I’ll try and display
it more clearly.
Cheers
I can confirm that selection is slower than it should be. The way to
find out why is to run VASSAL in a profiler with the module loaded. Then
you’ll be able to see what precisely is using the time during selection.
–
J.
Thanks for checking out the lag issue.
Do you have instructions on how to run Vassal in a profiler so that I can troubeshoot the problem?
Thus spake LB:
Thanks for checking out the lag issue.
Do you have instructions on how to run Vassal in a profiler so that I
can troubeshoot the problem?
Connect to the Player process with something like VisualVM.
–
J.
When attempting the process I described above, i.e. selecting a group of units, right clicking and selecting “Take Hit”, VisualVM reports that “javax.swing.RepaintManager$ProcessingRunnable.run()” took 8447ms, with 32 invocations.
The next line reports that “VASSAL.counters.Embellishment.getProperty(Object)” took 2021ms to run with 1,846,456 invocations.
Not sure exactly what that means but obviously Vassal is taking a long time to update the screen.
Edit: The above was tested with build 3.2.5 svn 8654 on Windows 7.
I profiled the same module using Vassal 3.1.20 and the results were “javax.swing.RepaintManager$ProcessingRunnable.run()” took 1267ms, with 35 invocations.
I’ve also noticed some visual artifacts appear around the playing pieces. E.g. Start a new game and place the “Human Heavy Cavalry” unit on the board. When it is selected, some visual artifacts appear around the unit. Deselect the unit, and those artifacts disappear. This happens with a number of other units. It occurs at all magnifications but is most noticeable at the 67% magnification.
Thus spake LB:
[This message has been edited.]
When attempting the process I described above, i.e. selecting a group of
units, right clicking and selecting “Take Hit”, VisualVM reports that
“javax.swing.RepaintManager$ProcessingRunnable.run()” took 8447ms, with
32 invocations.
The next line reports that
“VASSAL.counters.Embellishment.getProperty(Object)” took 2021ms to run
with 1,846,456 invocations.
Not sure exactly what that means but obviously Vassal is taking a long
time to update the screen.
Edit: The above was tested with build 3.2.5 svn 8654 on Windows 7.
I profiled the same module using Vassal 3.1.20 and the results were
“javax.swing.RepaintManager$ProcessingRunnable.run()” took 1267ms, with
35 invocations.
I had a look at the module myself just now. The problem is the
incredibly deep nesting of traits. It needs to be redesigned.
–
J.
Yes, there is a deep nesting of traits. But I don’t understand why that is the cause of the problem, especially since selecting and manipulating units in 3.1.20 is so quick in comparison to 3.2.5 8654.
It is because of the extensive use of layers with ‘Followproperty’ layers. In 3.2, these are being processed through beanshell as general expressions rather than via specific code. Let me look into it, I believe I can improve the performance for these cases.
Brent.
Thus spake Brent Easton:
It is because of the extensive use of layers with ‘Followproperty’
layers. In 3.2, these are being processed through beanshell as general
expressions rather than via specific code. Let me look into it, I
believe I can improve the performance for these cases.
Brent.
I tried caching the Expression in Embellishment.checkPropertyLevel(),
but that only shaved off a few percent of the total runtime—not
enough to be noticeable on its own. If it’s correct that the Expression
won’t change between calls of checkPropertyLevel, then caching it as
a private member of Embellishment would still be a good idea.
–
J.
Thanks for taking the time to look into this, I really appreciate it.
that will only help a little as the problem is mainly in the evaluation of the expression, not the creation. For a single property value, there is no need to create and evaluate a whole BeanShell Interpreter just to do a getProperty() call for us. I already have optimised sub-types of Expressions to handle numbers and strings, I have added a new one to handle single property values, as well as caching the Expression once it is created.
Using VisualVm, this appears to have speeded things up by about 40%. See how this goes. Other than that, the vast majority of the time is spent in VASSAL.tools.imageOp.ScaledImagePainter.draw().
The change is committed to Brent-3.2-p2p@8661
Thus spake Brent Easton:
Using VisualVm, this appears to have speeded things up by about 40%. See
how this goes. Other than that, the vast majority of the time is spent
in VASSAL.tools.imageOp.ScaledImagePainter.draw().
The change is committed to Brent-3.2-p2p@8661
It’s definitely much faster for me.
Merged to trunk@8665.
Try 3.2.5-svn8665:
vassalengine.sourceforge.net/builds/
BTW Brent, did you leave in some diagnostic print commands?
J.
Oops, yes, 5 of them around lines 746-769. Just delete them.
Have fixed this in Brent-3.2-p2p@3665.
Note you will need to apply 3663-3664 as well, these fix another related issue, but also contain a further fix for the follow property handling.
Thus spake Brent Easton:
Have fixed this in Brent-3.2-p2p@3665.
Note you will need to apply 3663-3664 as well, these fix another related
issue, but also contain a further fix for the follow property handling.
Merged. Try 3.2.5-svn8678.
vassalengine.sourceforge.net/builds/
–
J.
Thanks for the work guys!
There’s definitely a speed up and I’ll look at streamlining those pieces to improve the speed some more.
I’ve been using Vassal 3.2.5 and I’ve done some more digging and have found a major cause for slowdown/lag in the Battlelore module.
In the “Layer” trait, there is a tickbox titled: “Underneath when highlighted?”. In practically all the layer traits within the Battlelore module, this checkbox has been ticked. When I “unticked” the tickbox in all the layer traits, the lag became nonexistent.
I’m not sure why ticking this tickbox in the layer trait causes such a slowdown.
Hopefully this helps you guys in narrowing down where in the code this issue could possibly be caused.
Cheers
Thus spake LB:
I’ve been using Vassal 3.2.5 and I’ve done some more digging and have
found a major cause for slowdown/lag in the Battlelore module.
In the “Layer” trait, there is a tickbox titled: “Underneath when
highlighted?”. In practically all the layer traits within the Battlelore
module, this checkbox has been ticked. When I “unticked” the tickbox in
all the layer traits, the lag became nonexistent.
Is this new in 3.2.5, or does this also happen for older versions of
3.2?
–
J.
No this isn’t new to 3.2.5. It definitely occurred in 3.2.4 and 3.2.3. I’m not sure if it began from when 3.2 first came out but I do remember someone telling me that this module was lagging from quite a few versions ago.
It is caused by an internal inefficiency within vassal in the way it handles the Selection status of a unit. Turning ‘Underneath when Highlighted’ magnifies this inefficiency exponentially.
I have an idea on how to handle this fairly easily by caching the Selection status in each trait in the Decorator trait. Will get this done this morning for testing.