RPTools.net

Discussion and Support

Skip to content

It is currently Tue Apr 25, 2017 1:31 am 






Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Thu Apr 07, 2011 2:44 pm 
MageMirin wrote:
my win7x64 ultimate (pyr8 edition) system

TMI.


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Sat Oct 31, 2009 7:42 am
Posts: 49
Location: UK
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Thu Apr 07, 2011 4:14 pm 
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


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Thu Apr 07, 2011 6:19 pm 
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. :)


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Jul 01, 2008 6:48 pm
Posts: 6237
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Thu Apr 07, 2011 7:57 pm 
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).

_________________

What I'm Working On

MapTool Tutorials:
Introduction to Tokens
Introduction to Properties
Introduction to Macro Writing
Introduction to Light and Sight


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Thu Apr 07, 2011 10:45 pm 
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!


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Nov 10, 2009 6:11 pm
Posts: 7677
Location: Bay Area
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 1:33 am 
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?f=3&t=18419#p194912

_________________
Downloads:


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Jul 01, 2008 6:48 pm
Posts: 6237
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 7:24 am 
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?

_________________

What I'm Working On

MapTool Tutorials:
Introduction to Tokens
Introduction to Properties
Introduction to Macro Writing
Introduction to Light and Sight


Top
 Profile  
 
User avatar  Offline
RPTools Team
 
Joined: Thu Jun 01, 2006 1:05 pm
Posts: 5522
Location: Buffalo, NY
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 8:40 am 
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
Facebook: http://fb.com/billhartfitness


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 11:15 am 
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.


Top
 Profile  
 
 Offline
Cave Troll
 
Joined: Sat Oct 31, 2009 7:42 am
Posts: 49
Location: UK
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 11:28 am 
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


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Tue Nov 10, 2009 6:11 pm
Posts: 7677
Location: Bay Area
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 12:34 pm 
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.

_________________
Downloads:


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 1:05 pm 
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. :|


Top
 Profile  
 
User avatar  Offline
RPTools Team
 
Joined: Thu Jun 01, 2006 1:05 pm
Posts: 5522
Location: Buffalo, NY
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 2:00 pm 
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
Facebook: http://fb.com/billhartfitness


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12064
Location: Tampa, FL
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Fri Apr 08, 2011 9:24 pm 
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...

Quote:
- 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.

Quote:
- 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:

Quote:
- 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.)

Quote:
- 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. :)


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Fri Mar 28, 2008 11:30 pm
Posts: 1864
Location: Layfayette Hill, PA
 Post subject: Re: MapTool 1.3 Final, patch02 (build 85)
PostPosted: Sat Apr 09, 2011 1:33 pm 
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:

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

_________________
D&D3.5 / Pathfinder Framework


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 1 guest





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman