MapTool 1.1 Build 25 Progress

[trevor]

I got seriously ticked off with Java's ImageIO while trying to solve a couple image related issues over the weekend, so I ripped it out of my ImageUtil and reverted back to the old school image style.

It took a little reworking, so when this buid comes out, be sure to let me know if you find any image weirdness.

One advantage is that campaigns load much faster now.

As a completely unexpected side effect, animated gifs actually animate in the image explorer window. Weird. I mean, I know why it works, I just didn't expect my change to enable it. However, this doesn't mean it animates when dropping into the map. In fact sometimes the image just shows up as a black box. I'll work on that one. Get them animated ... later

My next trick is to solve the memory spike when clients connect. I've got a solution in mind and am half way through the implementation.

Then I'll drop in status halos for TheLevitator (he's been real patient), then make the next build. Should be thursday-ish.

[RPTroll]

I got seriously ticked off with Java's ImageIO while trying to solve a couple image related issues over the weekend, so I ripped it out of my ImageUtil and reverted back to the old school image style.

LOL. My mental image involves Trevor under the hood of the pimped out MapTools '67 Vette, yanking the carborator out, shaking it then throwing it on the ground while cussing.

[trevor]

I got seriously ticked off with Java's ImageIO while trying to solve a couple image related issues over the weekend, so I ripped it out of my ImageUtil and reverted back to the old school image style.

LOL. My mental image involves Trevor under the hood of the pimped out MapTools '67 Vette, yanking the carborator out, shaking it then throwing it on the ground while cussing.

That's actually fairly accurate

[trevor]

OK, got some really good memory usage updates in, using multiple images will now correctly only use the memory needed to show that one map. Loading campaigns is much smarter in avoiding Out of Memory exceptions when using mulitple large maps.

Now to tackle the memory explosion when connecting clients

[trevor]

I think I got the connect to server memory explosion under control now.

Basically what was happening is that when a client connects, it makes a request for all map images so that it can display the minimap. Obviously the right answer is the server should server the thumbnail first, and then get the big image in the background later, but that won't happen until 1.2

So anyway, back to the problem, when a client connects, it asks for all those large background images ... all at the same time. So the server tries to load all the images and send them over ... all at the same time. So putting all that in memory at once was causing a Big Bang.

My workaround solution (until 1.2) is to restrict the loading of images to one at a time.

A nice side affect is that if you are chatting, it only has to wait until the current image has transferred, and not ALL of them like it used to be.

Build 25 includes some very serious adjustments to some fundamental code. I was hoping to avoid that until 1.2, but it had to be done sooner to get 1.1 stable.

I'll try to play with it a bit more tonight and tomorrow, then make a build tmrw for you guys to play with, so I have enough time to fix things for the weekend players if something is totally hosed.

[Styles2304]

You're a fast worker and it's truly appreciated.

[Emryys]

You're a fast worker and it's truly appreciated.

No kidding!

Actually he's getting faster with age...

[Phergus]

So is MT sending the uncompressed image data?

In my test campaign with 200+ tokens the actual on disk size of the tokens was only 8MB. I was using a unbound map.

Hmmm. Even uncompressed it doesn't seem like that would take up 256+ MB of memory. Only 32MB on the high side actually.

[trevor]

MT sends the byte data, the same that is found on the disk. Not sure why your numbers are low. Keep in mind that it only sends images that are requested, and not all the images in the campaign.

Even uncompressed it doesn't seem like that would take up 256+ MB of memory. Only 32MB on the high side actually.

I'm a little confused, are you still talking about disk space, or runtime memory ?

[Steel Rat]

LOL. My mental image involves Trevor under the hood of the pimped out MapTools '67 Vette, yanking the carborator out, shaking it then throwing it on the ground while cussing.

Lol, I was picturing an XKE convertible, and he's got two carbs, one in each hand.

[Phergus]

1) Create campaign with a single, unbounded map from one of the default textures.
2) Place 200 different tokens on map.
3) Make all tokens visible.
4) Start server.
5) Flush image cache on client PC.
6) Start client.
7) Connect to server.
Watch server memory usage max out and spew out heap memory errors.

Disk space for 200 tokens: 200 * 75KB avg = 15MB
Memory space for 200 tokens: 200 * (200px * 200px * 4bytes) = 32MB

Both 15MB and 32MB are waaaay under 256MB and yet the server runs out of memory serving those 200 tokens to a single client.

[trevor]

Those are 200 different tokens, right ?

[Phergus]

Correct.

[trevor]

1) Create campaign with a single, unbounded map from one of the default textures.
2) Place 200 different tokens on map.
3) Make all tokens visible.
4) Start server.
5) Flush image cache on client PC.
6) Start client.
7) Connect to server.
Watch server memory usage max out and spew out heap memory errors.

Could you email me your campaign file ? I tried this last night and didn't see the server memory spike.

[Phergus]

On it's way.