Hi! I’m creating a new game/module about ww2 (I’ve been working every night for a year now) but I haven’t finished creating it yet (I’m putting all the tiles on the board) and it already takes more than 30 seconds to load the screen and more than 15 seconds when I move from one part of the map to another. I don’t know what the cause is.
The images are about 200, PNG files created from the module itself, almost all of them, in many different colors. The counters I’ve created so far should be about 300 on the Main Map and another 300 on other Windows. I’m not using layers or send to or computing anything at the stack level. I have 3 prototype definitions for the units of each force with 10 calculated properties, 10 dynamic properties and 10 text labels each, more or less. The board has 4.900 Kb. The module has 5844 Kb. The memory is in 1024 but it didn’t change anything if you put it in 512 or 4096. The time increases noticeably when adding more images and counters. What can cause performance to deteriorate so much? Can anybody help me? Thank you!!!
That’s pretty heavy usage of Calculated Properties. If any of them are directly referenced in Text Labels, it could very easily be a big contributor to the delays you’re seeing.
Excellent info Joel! Removing almost all text labels with calculated properties time drops to 1/4. Thank you very much!
Try to avoid, as much as possible, beanshell expressions in all text traits. In fact, why the hell are they allowed in the 1st case. A text trait should allow just that - text - said text can just text or property value ($xxx$) as per what used to be the norm.
CPs solve some problems which are hard to solve other ways. You’re not required to use them; it’s up to you.
There should be a warning though. Like ‘Using beanshell expressions in a text trait will seriously affect system response timings’ or something along that line. Far better to use a CP or DP then use that property in a text trait.
BTW, not talking about CPs, but the ability to use beanshell expressions in text traits.
From the Calculated Property trait description in the Reference Manual:
“…module designers should be aware that long complicated chains of Calculated Properties can therefore lead to “lag” and slower performance.”
Get over it. Not CPs. Beanshell expressions in text traits is the issue. NOT CPs.
Yeah, I missed that. My bad.
Not clear (to me) that substituting a beanshell expression from the text labels and replacing with a calculated property would necessarily make things faster. In effect all you have done is move the location of overhead processing.
Unless you truly need real-time updates (i.e., calculated properties), it is possible to use a dynamic property linked to a command key which could be triggered either manually or at end of a phase/turn/year/whatever.
This is the one thing you definitely don’t want to do at all. Even a couple instances of having an omnipresent Text Label directly referencing a CP results in immediately crippling slowness.
What I’m less sure about is how much use of expressions in Text Labels is enough to introduce deleterious effects. It’s easy to whip up small test modules that employ this with no noticeable impacts–but I can easily imagine it being bad when scaled up (either more expressions period and/or more complex ones). I just don’t know how much is too much.
Text has the same performance cost as Layer when Layer is using Levels follow expression value. The later includes this warning in its Reference Manual section:
Note that larger expressions (e.g., comparisons, arithmetic, etc.) are permitted, but performance may suffer as this expression will be checked every time a piece with the expression is drawn
As I understand it, the piece will be drawn not just when the itself piece changes but whenever any element of any displayed Vassal window changes. e.g. when another piece is dropped, possibly even when a piece is selected.
As an aside: Layer also has a special setting (“Only show layer if property”) to bypass recalculation of the Layer but I’m not sure why this is any better than checking that property as the first step in the “expression value” field.
To the point about documentation, I propose to update the Text Label reference section to include something similar to that included for Layer.
I propose PR# 13737 to add a highlighted box note below the Label Text evaluation list in the Text Label trait reference section, as below:
Would that help?