AJAX boardgame runs fine in Windows, but not in Linux

Question

I have been playing a web boardgame called Empires at GamesByEmail.com recently. It runs fine under Windows, but is unusably slow on Linux.

I asked the developer why. He uses Linux, but he does not know. He suspects there are too many DOM elements, but he does not know what to do about fixing the problem.

It's slow both in Firefox and Google Chrome, so it does not seem to be a browser issue.

I was testing my own site with Firebug and the Page Speed extension, so I thought I'd try it on GamesByEmail. The results are up at ShowSlow - http://is.gd/5QSRM. It is actually quite fast from a conventional web development point of view - it's just broken on Linux.

Please can all you skilled Linux devs check out the game and give us some clues?

http://gamesbyemail.com/Games/Play?475162291

Answer 1

Google Page Speed tests how well a site follows best practices for performance, not how well it actually performs. If the site is sluggish in Chrome, try Google Speed Tracer, which will profile what the browser is doing on the site. Compare its output between windows and linux.

Answer 2

edit:

Ok this is a horrible design. It loads tons of gifs (2 for each area) which are the size of the playing field (947x622) and overlays them. Then on mouse over it switches the two. In any case, this is the cause of the bad performance, I expect.

Did that help? Now that you know how it was implemented badly, what does it matter really? Just play it on windows.

original post Ok, saying something is fast on windows and slow in linux means nothing. You could be running it on a 8gb quad core with a huge disk for windows and a netbook for linux. This would make it slow. So tell us... what are the technical differences between the two machines. My guess is the linux machine has less memory and this application likes a lot of memory for the java and graphics.

Answer 3

just some additional feedback: the game appears to be incredible slow in Mac OS X Firefox, too - had to relaunch the 'fox after it froze..! Ouch!

Answer 4

Hi guys,

I'm the guy that wrote the "horrible design" called "Empires" :O

Initially I knew it would be a lot of logic, but I had no idea what I'd gotten myself into.
In the end, knowing there were performance issues (esp. on Mac and Linux), I figured I'd be best off to at least make it playable, patch it up as best as possible and get it out there so me and some friends could play the game.

Turns out as the game gets closer to Epoch 7 performance gets pretty bad. (so many pieces on the board). Iain, ealier when I mentioned there were too many DOM elements, it 's the many many images that I was referring to.

The main dev behind gamesbyemail.com (who makes awesome games, and don't let Empires fool you about the quality of his games!) he mentioned that there was very little difference in performance between a small gif and a board-size gif which is mostly transparent.

The problem is that attempting to clone HoTW-2001 resulted in using a lot of images.

There's some optimizations I've got ready to go here, but haven't had the time to finalize. (It'll take me about 12 hours or so to play-test everything before release, and even then it's easy for bugs to get through :(
But, I do have plans to:

• Eliminate all pngs (if I haven't already... there's a var in there that toggles between gifs or pngs. I so love the tranparency of pngs, but that extra channel doubles the image size :(
• Turn off the pulse effect.
  I wanted this on to help identify "the current empire" as opposed to "previous empires" owned by the same player. The problem is that the animation is just far to expensive for most browsers :( (I know, I should probably be using flash or the canvas tag, but Scott's API is so tantalizingly rich and robust... too much to possibly implement on my own).

So ya... I just have to get off my butt and get on it with at least the items above.

Troy

PS - Another URL to use for testing the game might be the game preview here. You can play out an entire game as all players.

Answer 5

Another idea.

The original API is more suited to games that use flat-colored territories (like Gambit and WWII). So, instead of generating thousands of gifs which contain speckly shading (makes for a bigger image) I either:

• Revert to pngs, use a single color, eg: blue, but at 30% transparency and let the underlying board provide the shading and the texture. OR
• Use gifs, a single flat color, no shading, and use DOM properties to display it semi-transparent (this is already done in some places using a few different browser-specific dom properties). Only challenge would be to make it look good visually.

The possible benefit here would be to reduce the size of data transmitted per image request. It still leaves the problem of a large number of requests though.

Finally, there's the possibility of combining this approach with a spriting approach, and instead of rendering thousands of separate images from the master map(gimp image), I render the territories to a single giant image(with extra transparent space around each territory).

So, some ideas I can pursue... uh, as my schedule opens up :)

Troy

Answer 6

Hi guys,
I've been doing some profiling today. Here's a sample of the data from an Epoch 7 save game I have here. Pretty close to worst case scenario, and, this is with pulsing off, so I'm starting to think maybe I can get away with the pulsing and the problem is elsewhere.

Function        Calls   Percent Own 
                                Time(ms) Time(ms)        File
mouseEvent()    658     4.69%   75.67   1596.14 GamesByEmail.js (line 4150)
onmousemove     576     1.07%   17.32   1575.29 26 (line 1)
mouseMove()     576     1.18%   19.04   933.05  Game.js (line 2122)
findAtPoint()   576     4.14%   66.9    594.48  EmpiresT...ritory.js (line 415)
containsPoint() 16217   6.00%   96.91   518.51  GamesByEmail.js (line 5676)
normal()        16217   14.65%  236.61  421.59  Foundati...ometry.js (line 485)
cancelScroll()  658     21.51%  347.38  347.38  GamesByEmail.js (line 4109)
mouseMoveHidePrevious()
                576     0.18%   2.94    266.65  Game.js (line 2153)
updateMouseHtml()61     0.16%   2.64    256.51  Game.js (line 2178)
updateMouseHtmlPosition()
                639     11.69%  188.87  216.47  GamesByEmail.js (line 3783)
setMouseHtml()  61      0.53%   8.58    206.75  GamesByEmail.js (line 3767)
containsPoint() 16217   5.78%   93.41   144.65  Foundati...ometry.js (line 312)
setInnerHtml()  61      1.99%   32.19   116.9   GamesByEmail.js (line 2578)
toString()      183     6.40%   103.33  103.33  Foundation.js (line 476)
washHtml()      61      0.10%   1.54    84.71   GamesByEmail.js (line 2566)
insertStyleForElements()
                122     0.40%   6.49    83.17   GamesByEmail.js (line 280)
mousePoint()    578     2.57%   41.53   67.59   GamesByEmail.js (line 4119)
containsXY()    16217   3.17%   51.24   51.24   Foundati...ometry.js (line 308)
getElement()    1008    1.98%   31.98   41.18   Foundation.js (line 507)
normal          16411   2.50%   40.34   40.34   Foundati...ometry.js (line 487)
Point()         1155    1.88%   30.34   36.38   Foundati...ometry.js (line 15)
canAttack()     614     0.30%   4.79    35.41   Empire.js (line 477)
... 

What I'm seeing indicates all the time is eaten up inside mouseMove and its subfns. Determining which territory the mouse is over is normally an O(n) job. Iterate through each polygon of each territory until we find one containing the mouse X,Y. (things like "normal()" are a part of that process. It uses bounding boxes too, so some optimization there).

But I don't understand how this performance can become so much worse at the end of the game (with lots of territory overlays) versus the start of the game with very few territory overlays. Searching through the territories to determine which one the mouse is in might not itself be the problem... but some side-effect that gets incurred while doing this, OR, that browsers on Linux and Mac are getting overwhelmed by the volume of DOM elements created by having so many tiny images onscreen(?)

Guestimate of images onscreen:

• maybe 120 images for coloured territories
• another 130 or so for highlighted territories
• the "pieces.gif" sprited to show monuments, cities and army guys, another 240+ of those

That alone is about 500 gifs onscreen at once, or 250gifs and 1 gif sprited 240 times

This suggests either myself of the underlying API is doing something really expensive when a territory has a coloured overlay. (because at the dawn of history performance is pretty good when mousing around the board).

Could be I have to review all the code inside territory.updateHtml(); (who was it that said this wasn't a code question?... ha! I don't think he's seen the 15000 lines of spaghetti madness javascript I've written :o ).

Maybe I should run a similar profile run from Epoch 1 to see what that looks like? I'll post if I find out more.

Troy

Answer 7

Hi guys,

@Hogan & @CasualCoder, there's been some discussion in the back-channels along exactly the lines you mention: That performance suffers as the game progresses due to the large size images used for coloured overlays. The game uses:

• 129 Highlight images (makes territory glow during mouseover)
• 92 Coloured overlays (shows which player owns the territory)
• 129 IMG tags for the Pulse effect (repeats of the 129 hilite images).

=350 IMG tags.

At the start of the game, the 92 Coloured overlays are 1x1 pixel blank images. The highlights are 1 image per territory, mostly transparent, matching the size of the board, but usually only 1 is visible.

As the game progresses, the overlay images are replaced by images which show a single territory in red or blue etc. depending on which player owns it. These coloured overlays are the same size as the board, although mostly transparent. At the time we figured these images would render as fast as smaller cropped images (and this seemed to be the case in some of the older IE browsers in windows).

But, based on some other test result feedback I've gotten there seems to be a lot of support that these 947x622 sized overlays are the problem; combined with whichever highlight images are also visible.

This is a worst case of up to 92 visible IMGs for conquered territories, plus maybe a dozen or so IMGs being pulsed for current empire = 105 947x622(boardsize) stacked images. The concern is that this is causing the extreme slowdowns when moving the mouse around in Linux and Mac browsers.

I edited my gimp scripts to instead generate the highlights and overlays as tightly cropped as possible, and output offset X and Y data to text file (which I then pasted into the code and use to position the new images relative to top-left corner of board).

The new implementation seems to be performing better here in my dev environment (am hoping I'm not being too faked out by localhost here). As soon as I can get it online and tested some more I'll update the comment here.

Thanks again for the feedback guys, I'm hoping the new cropped graphics address the problem.

Troy

Edit: The latest cropped images code for Empires is now online. Just awaiting more general feedback, but so far it seems to feel much more responsive in both Windows FF and Ubuntu FF! Thanks again for the help everyone :)