MapTool 1.3 Final, patch02 (build 85)

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

MageMirin wrote:my win7x64 ultimate (pyr8 edition) system
TMI.

suntzu777
Cave Troll
Posts: 27
Joined: Sat Oct 31, 2009 8:42 am
Location: UK

Re: MapTool 1.3 Final, patch02 (build 85)

Post by suntzu777 »

i found it very laggy only when i started the server , if i didn't start the server there didnt problem , this is running on osx 10.6.7 with 8 gig and 4 x i7 pro's so went back to r84 and everything was fine

Rob

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

suntzu777 wrote:i found it very laggy only when i started the server , if i didn't start the server there didnt problem , this is running on osx 10.6.7 with 8 gig and 4 x i7 pro's so went back to r84 and everything was fine
Thanks.

Which campaign file are you testing this with? The .rpmap I linked to or something else?

I can sort of understand the server thing -- obviously there's going to be network traffic. (Even without players. When you StartServer, MapTool creates a background job that runs the server and the MapTool application becomes a client to that server.) It just occurred to me that it could be that the map object (called a Zone in the code) is being sent when certain fields are being changed. I'll look into it.

Thanks again. :)

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Rumble »

Just as another data point, Az, I tested the imported rpmap file, without clearing any fog, and it was a touch laggy without a server running, and OMG LAG with the server running - it took something like 15 seconds to move a token 6 squares; heck, it took 15 seconds to respond to a click on the "X" to close the program.

This is, again, on Windows 7 Home Premium 64-bit Foosball Unicorn edition, SP1 (TM(C(R))), and launching from the website (launching via the MapToolLauncher file showed the same behavior).

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

Rumble wrote:[...] and OMG LAG with the server running
Wow. At least that implies that the problem is at the network layer. (Can you test it by resetting the fog, too? I'm just curious.)

It likely has something to do with objects being serialized before sending over the network and with the server running, the local client does all of that same work when talking to the server that's running in the background. An obvious optimization is not to serialize it when talking to 'localhost', but that wouldn't help with players connected...

Well, note to self: don't put 5 levels of very complicated VBL on a single map!

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch02 (build 85)

Post by aliasmask »

Speaking of weird lag. I made a macro which runs very quickly on the local machine, but propagating to the client computers takes forever. It happens with the Wiki: setInitiative() function. It literally takes 1 second or more per token to update. This is with 4 clients and 6 tokens. Basically what you see is the token init change once every second, then the sort kicks in.

Here is my code: http://forums.rptools.net/viewtopic.php ... 19#p194912

User avatar
Rumble
Deity
Posts: 6235
Joined: Tue Jul 01, 2008 7:48 pm

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Rumble »

Azhrei wrote:
Rumble wrote:[...] and OMG LAG with the server running
Wow. At least that implies that the problem is at the network layer. (Can you test it by resetting the fog, too? I'm just curious.)

It likely has something to do with objects being serialized before sending over the network and with the server running, the local client does all of that same work when talking to the server that's running in the background. An obvious optimization is not to serialize it when talking to 'localhost', but that wouldn't help with players connected...

Well, note to self: don't put 5 levels of very complicated VBL on a single map!

I had a second to try this out this morning (running MT with 1024MB RAM, and a 2MB stack, and launching locally from MapToolLauncher rather than from the website).

Results: with the fog reset before I did anything else, there was no lag at all, with or without a server. Snappy as all sorts of snappy things. If it was any snappier, it'd be a mousetrap. So, from that it seems like the issue is complex fog, but it gets a lot worse with the server running?

dorpond
RPTools Team
Posts: 5534
Joined: Thu Jun 01, 2006 2:05 pm
Location: Buffalo, NY

Re: MapTool 1.3 Final, patch02 (build 85)

Post by dorpond »

Azhrei wrote:This is likely the last update for MT 1.3.
*Grins at Azhrei*
I told you, you have to release with "Here is another release - let me know how bad it is" and it will be the best release ever! :lol:
How to use my bundled artwork (MT1.3B60+): http://forums.rptools.net/viewtopic.php?f=8&t=11759

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

aliasmask wrote:I made a macro which runs very quickly on the local machine, but propagating to the client computers takes forever.
It sounds like there's some problem with the client/server connection. But the clientserver project (an RPTools library which MapTool uses) hasn't had any changes to it that I know of.

I'm running a network capture right now to see if I can determine whether it's network related or something else.

suntzu777
Cave Troll
Posts: 27
Joined: Sat Oct 31, 2009 8:42 am
Location: UK

Re: MapTool 1.3 Final, patch02 (build 85)

Post by suntzu777 »

Azhrei wrote:
suntzu777 wrote:i found it very laggy only when i started the server , if i didn't start the server there didnt problem , this is running on osx 10.6.7 with 8 gig and 4 x i7 pro's so went back to r84 and everything was fine
Thanks.

Which campaign file are you testing this with? The .rpmap I linked to or something else?

I can sort of understand the server thing -- obviously there's going to be network traffic. (Even without players. When you StartServer, MapTool creates a background job that runs the server and the MapTool application becomes a client to that server.) It just occurred to me that it could be that the map object (called a Zone in the code) is being sent when certain fields are being changed. I'll look into it.

Thanks again. :)
the campaign file is a game which has been running for a few months using rumble's framework , there are alot of monsters , rooms with vbl , the campaign file is about 45 meg

Rob

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch02 (build 85)

Post by aliasmask »

Azhrei wrote:
aliasmask wrote:I made a macro which runs very quickly on the local machine, but propagating to the client computers takes forever.
It sounds like there's some problem with the client/server connection. But the clientserver project (an RPTools library which MapTool uses) hasn't had any changes to it that I know of.

I'm running a network capture right now to see if I can determine whether it's network related or something else.
Actually, I'm still using b84, so it's not a new thing to b85. But I only recently created the macro, so the problem is new to me.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

Azhrei wrote:I'm running a network capture right now to see if I can determine whether it's network related or something else.
Weird stuff. It appears that there are 1-, 2-, and 3-byte packets sent all the time. Apparently some kind of heartbeat or something. Images and other data are compressed and sent in large chunks (I mostly see TCP packets of 1024 bytes or 16332 bytes). I'm going to look into updating the Hessian library first (to see if the newer version is more efficient). If that doesn't fix it, I'll spend a little time profiling the network layer but something that fundamental may need to wait for 1.4. :|

dorpond
RPTools Team
Posts: 5534
Joined: Thu Jun 01, 2006 2:05 pm
Location: Buffalo, NY

Re: MapTool 1.3 Final, patch02 (build 85)

Post by dorpond »

OK, I imported the map you posted Azhrei and I did my tests. This is what I have found:

- Performance does get a lot worse by just starting a server. For giggles, I also tested this in B82 and it was just as bad, if not worse, with this map.
- Doesn't seem to be VBL related because once I remove all VBL, the terrible performance doesn't change.
- FOW does seem to play a huge part with the performance hit; if I fill in all FOW, performance improves (server not started).
- As soon I imported the map, I switched to View as Player (moved a token) and performance got so bad that Maptool was virtually unusable:

(1.3B82)
Timer zonerenderer: 23792
calcs: 439
fog: 14250
labels: 9069
tokenlist-1e: 23324
tokenlist-9: 13
tokens: 26

(1.3b85 - server not started)
Timer ZoneRenderer.renderZone (62 elements)
2. calcs: 195 ms
53. renderFog: 296 ms
57. renderFog:combined: 259 ms
58. renderFogArea: 33 ms
60. visionOverlayGM: 310 ms

(1.3b85 - server started)
Timer ZoneRenderer.renderZone (59 elements)
2. calcs: 162 ms
46. tokenlist-1e: 1476 ms
49. labels: 406 ms
50. renderFog: 306 ms
54. renderFog:combined: 271 ms
55. renderFogArea: 32 ms
57. visionOverlayPlayer: 762 ms

- If I do the above tests after I completely fill in FOW, it is still pretty bad with 'view as player':
Timer ZoneRenderer.renderZone (60 elements)
2. calcs: 27 ms
45. tokens: 21 ms
47. tokenlist-7: 18 ms
47. tokenlist-1e: 754 ms
51. renderFog: 196 ms
55. renderFog:combined: 160 ms
56. renderFogArea: 33 ms
58. visionOverlayPlayer: 553 ms

- It doesn't seem to matter if the server is started with Individual FOW = On or Off - same results.
- Whew, view as player while a server is started - just another set of numbers for your viewing pleasure:

Timer ZoneRenderer.renderZone (59 elements)
2. calcs: 191 ms
45. tokens: 27 ms
46. tokenlist-1e: 8289 ms
50. renderFog: 4072 ms
54. renderFog:combined: 4049 ms
55. renderFogArea: 19 ms
57. visionOverlayPlayer: 4199 ms

My test report is a bit jumbled chaotic and jumbled here, but I thought the performace values will be of some help to you. Nevertheless, with this map, b82 was just as bad if not worse. I will do more testing with my campaign file that I have been using for years and report back.
How to use my bundled artwork (MT1.3B60+): http://forums.rptools.net/viewtopic.php?f=8&t=11759

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch02 (build 85)

Post by Azhrei »

Thanks, Bill. Great info. :)
dorpond wrote:- Performance does get a lot worse by just starting a server. For giggles, I also tested this in B82 and it was just as bad, if not worse, with this map.
As I would expect; we've made quite a few tweaks to the fog over the last few builds...
- Doesn't seem to be VBL related because once I remove all VBL, the terrible performance doesn't change.
Ah, I should've thought to check that. Thanks.
- As soon I imported the map, I switched to View as Player (moved a token) and performance got so bad that Maptool was virtually unusable:
[...]
- If I do the above tests after I completely fill in FOW, it is still pretty bad with 'view as player':
Timer ZoneRenderer.renderZone (60 elements)
2. calcs: 27 ms
45. tokens: 21 ms
47. tokenlist-7: 18 ms
47. tokenlist-1e: 754 ms
51. renderFog: 196 ms
55. renderFog:combined: 160 ms
56. renderFogArea: 33 ms
58. visionOverlayPlayer: 553 ms
Thanks. I noticed that #47 showed up twice and that shouldn't happen. The CodeTimer is supposed to increment the value each time a new data point is created (although only data points of 10ms or more are reported). So two 47's shouldn't happen. I've fixed that bug.

I also found a bug in the reporting of the numbers for tokenlist-1e. I couldn't understand how those numbers could be so large!

It's not good when your code to track performance has bugs in it! :oops:
- It doesn't seem to matter if the server is started with Individual FOW = On or Off - same results.
Hm, good info. The GEA (Global Exposed Area) and TEA (Token's Exposed Area) have to be merged now each time a token is selected. I insisted Joe make this change as it's more accurate, but if it's going to be a performance problem we may have to change the way this works. (Joe: whenever a new zone renderer is made current we could start a new cache. If a token's fog is in the list we use it and bypass the renderFog() work. Keeping the cache current may be a pain though. I'll consider this as I look through the code.)
- Whew, view as player while a server is started - just another set of numbers for your viewing pleasure:

Timer ZoneRenderer.renderZone (59 elements)
2. calcs: 191 ms
45. tokens: 27 ms
46. tokenlist-1e: 8289 ms
50. renderFog: 4072 ms
54. renderFog:combined: 4049 ms
55. renderFogArea: 19 ms
57. visionOverlayPlayer: 4199 ms
I believe the bold line is the problem. Unfortunately, profiling the code doesn't show enough detail to indicate which parts in particular are taking so long. I fear it's the merging of the various fog pieces though. That could be a problem. :( I plan to split the renderFog() method into small pieces so that hopefully the profiler can help isolate the issue.

Thanks a bunch for all that work, Bill -- good stuff. :)

User avatar
lmarkus001
Great Wyrm
Posts: 1867
Joined: Sat Mar 29, 2008 12:30 am
Location: Layfayette Hill, PA

Re: MapTool 1.3 Final, patch02 (build 85)

Post by lmarkus001 »

First, thanks so much for everyone's hard work on this!!!

Ran a session last night and encountered some issues, but most notably the Lock-Player_movement mouse move error bug is still very much alive and present.

I was very busy DMing, but did manage to capture some of the error info.

Configuration: 9 clients, 1 server

Server (no human interaction on this machine): WinXP-32, recent Java
Clients: Win7-64, Win7-32, Vista-64, Vista-32

When I would move a token on a client, both the client and the server would show the movement path real time, but when I would drop the token to complete the move, the server would take 4+ seconds to register the move.

When I turned on Lock-Player-Movement (GM client connected to the server) I received this error:
LockPlayerMovement
java.lang.NullPointerException
at net.rptools.maptool.client.AppActions$50.execute(AppActions.java:1710)
at net.rptools.maptool.client.AppActions$ClientAction.actionPerformed(AppActions.java:2691)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.JToggleButton$ToggleButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at de.muntjak.tinylookandfeel.TinyMenuItemUI.doClick(TinyMenuItemUI.java:571)
at de.muntjak.tinylookandfeel.TinyMenuItemUI$MouseInputHandler.mouseReleased(TinyMenuItemUI.java:421)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:25)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
From that point onward, player movement was locked if they did not have initiative, and no matter how I toggled the checks player movement remained locked if they did not have initiative. Sometimes to resolve it I would Boot the player and they would use the OS to stop the Maptools task and then come back.

Additionally players randomly would get the mouse-move error (this especially occurred if they tried to move their token when it was not their initiative). I thought my players had recorded the error and posted it up for me, but it seems they just gave me lip service... sorry.

Anyway, lock-player-movement continues to be broken (it has been broken for 84 onward, but was fine before that).

---------------------------

Typing Notification

When I had multiple people tying and running macros, performance got hammered. Once we disabled Typing Notifications performance became MUCH better. This is NOT new to b85.

-----------------------------

Shift Mousemove

My players really appreciated this feature, but suggested there be an application setting that lets you choose if Shift-Move hides or displays the statsheet, if toggled, then the default would be to hide the statsheet and you would need to hold down Shift to see the statsheets.

----------------------

Very Busy Map / Map-Export-Import

My group is on a very busy map so I exported it, then imported and reset the fog. I then ran with global fog (not individual views). No one noticed particularly bad movement performance. But I did discover errors/oversights in the export-import mechanism.

When a map is exported then imported, the following token properties were lost:

[*]Player Vision setting: the PC tokens with Has Sight all were reset to Normal. None of my NPCs had vision so I can not comment on that.
[*]Token Ownership: All token ownership information was lost

Post Reply

Return to “Announcements”