MapTool 1.5.2 Edit Token view is very slow to initialize.

[adventuremagic123]

Describe the bug
Edit Token view is very slow to initialize.

To Reproduce
Steps to reproduce the behavior:

1. Double-click on a token.
2. Takes about a minute for Edit Token to become usable.

Expected behavior
For MapTool 1.4.1.8 and a copy of the same campaign, doing the exact same thing to the same token on the same map takes about 1 second for the Edit Token view to come up and become usable.

Screenshots
If applicable, add screenshots to help explain your problem.

MapTool Info

• Version: 1.5.2
• Install: New

Desktop (please complete the following information):

• OS: Windows
• Version 10

Additional context
I copied the campaign I was using in MapTool 1.4.1.8 and now use that copy exclusively with MapTool 1.5.2. It has two token types which each have over 10,000 token properties (and, yes, I'll be working to change that now that I know a lot more about MTScript and how to write complex code with it!).

[Phergus]

A campaign with an empty map but for 2 example tokens would be helpful.

[adventuremagic123]

Here you go.
Empty Map with Two Tokens.zip

[adventuremagic123]

There was no problem when no campaign was loaded. I had one player connected remotely the same way we did during the game. The Edit Token view also comes up with no trouble -- no delay.

[Phergus]

In that case, I would suspect some macro being run whenever a token is selected. The changes for the addition of multi-line property editing may be the root cause of the slow-down.

However, the nearly 3000 properties aren't helping either. The vast majority of that could be moved to either JSON arrays or String Prop Lists.

[adventuremagic123]

I did it that way because I didn't at the time know how to use library tokens and MTScript seemed very limited with the 2 level nesting limit, so I didn't want to try complex logic.

Also, early in development I didn't have time to support having dialogs and wanted non-programmers to be able to edit token properties directly in the Token Editor.

But that all aside, it works fine in 1 4.1.8 with no performance issue, so this issue seems to point at a scalability issue in 1.5.2.

[adventuremagic123]

So, in other words, there's a new limitation here that would be nice not to have.

[adventuremagic123]

BTW, you didn't seem to notice my comment that a token with all those properties opened in about 1 second with no campaign loaded. Something else is going on besides the unruly number of token properties or multi-line property editing.

[adventuremagic123]

Oh, no, you are probably right. The scaling issue is associated with the number of token properties. My no campaign test means no token type was used for the token -- or basic. Anyway, something with much fewer token properties.

[Phergus]

I wondered if that may have been the issue.

The reason I bring up the multi-line properties is that now that properties table has syntax-highlighting, word-wrapping text areas instead of simple text fields. There may be a significant overhead in initializing so many.

If you can, grab 1.5.1 and install it in a different folder somewhere. They can coexist without issue. Load up your 1.4.1.8 campaign file in it and see if the edit token lag is there. 1.5.1 didn't have the multi-line props.

Strike that. Tested with the campaign you provided and the speed in all versions of 1.5.0. Going to need to do some profiling to figure this out.

[adventuremagic123]

Ok. Thank you very much for working on that. My preference would be to have scalability over a fancy editor -- however I can see a need for that when writing more complex code using JSON. So, we're all probably hoping we can get the best of both worlds.

Maybe the best thing to do would be to have two modes for each token property in the token editor: view mode and edit mode.

View mode just shows the data as it is, but you can't change anything. However, once you click on the data part of the property, it switches to edit mode with the syntax highlighting, word-wrapping text area.

Alternately, let us choose whether we want the text area editor or the simple text editor. Clearly, my grossly simple implementation as it is does not benefit from using the text area control -- but it will after I refactor the code, start using JSON, start using library tokens, and make it a lot more efficient. If there was still a performance issue at that point by using the text area control, I'd still very much want the option of having the choice of using the simple text control.

I think that might be the fix. Give us the option for which control we want to use -- with a warning about potential performance issues when using the text area control.

[adventuremagic123]

Probably a better approach is to only instanciate the new editor if the data type of the field is JSON.

[Merudo]

Is this bug still occurring?

[JamzTheMan]

Yea, its especially noticeable with tokens that have larger sets of data.

I notice it more if I open one token then close and open another. I can see the old properties for a second then it "refreshes" to the new token.

[Phergus]

Yeah. Still there. 1.5.6 seems a bit slower than 1.5.14.

This campaign has 1300ish token properties.
LotsOfProps157.cmpgn.zip