MT 1.3b62 Progress

[jfrazierjr]

Sorry guys.. I did not mean to imply that the slow down between versions was localized to specific frameworks. Just more of a general "hey, here is one reason why stuff is slow based on what I have experienced".

Two things I can see of the top of my head that will need to be worked on in future releases:

1) switch to javascript should greatly improve the parsing speed of json stuctures as well as get rid of a good bit of kludgy code.

2) remove the token's property change event and have the hook for updates to tokens coded into the end of the macro execution so that only a single update is performed no matter how many changes are done to the token. The big issue with this is figuring out how to deal with macros that update multiple tokens. One possible way is to create a queue with tokenid's as things are changed and then at the end of macro execution, "sync" tokens that are in that queue to the other clients.

[trevor]

Sorry for the delay, weekends are brutal over here.

For a point of reference, when you drop a token, it has to transfer the entire token(s) back to the server. So the more content on a token, the longer the delay is.

So it won't be rendering code, it'll be in the transfer of the token.

That doesn't explain why it would be different between two versions using the same framework.

Could someone send me a campaign file with the framework that this is seen in, along with steps to reproduce (even if it's just "move token X"). I'll see what is taking up the time.

[Rumble]

Trevor:

Here's a link to a bug reports thread I started on this - there are two campaign files attached, one saved in b56, and the other the same campaign, but saved in b61. I've put instructions to show what I was doing to compare the macro handling speeds.

http://forums.rptools.net/viewtopic.php?f=21&t=12185

I hadn't really noticed the drag/drop speed issue until someone else pointed it out; I assumed it was just because the campaigns I was using were big and had lots of images.
I don't have a specific example for the token moving delay, but you may be able to see it between those two campaigns anyway.

Hope these help!

[Chrest]

I'm guessing is an inefficiency of the drawing routine. For example, you drag the tokens and let go and it goes back and recalculates the A* path over and over, once for each token, when the pathing had already been done so that it could be displayed. Or perhaps it's the process of moving the tokens -- longer drags seem to have a larger lag, so perhaps MapTool is moving each token each step, then moving it again for the next step, and so forth. That might have happened when the code was added to prevent players from dragging tokens into an area of VBL, back around the mid to late 40's. Or perhaps it's related to fow exposures at each step of the path being taken? (Note that MT is necessarily doing that, but the code may not be optimizing it correctly.)

Forgive my ignorance, but why is MapTool using A* search for path calculation? I didn't know that MapTool ever did anything but calculate direct routes between a series of points. Movement rules will change the exact path that tokens take, but I didn't think MapTool ever routed around obstacles; wouldn't a small dedicated path function for each possible movement type be more efficient (in memory usage or CPU usage or both) than A* search?

[Azhrei]

Perhaps short-term. But there have been plans for a movement blocking layer for a long time. Why invent a specialized routine when a generic one -- that will be useful in the future -- is well-known?

That, and the fact that A* routines are cool.

[trevor]

The original intention was to make it possible to have obsticles to work around automatically, like walls and tables and such, it just hasn't gotten high enough priority to implement yet.

[trevor]

Update
I apologize for the delay, I've been out of town on a business trip.

Work is slowly moving forward on b62 as I can get time. Currently I'm working with a few macro developers to figure out the slowness issue. I'm hoping we can nail that and do a build this weekend.