AJAX Board Game Works Great on Windows, but Not Linux

Question

I recently played a web game called Empires at GamesByEmail.com . It works fine under Windows, but on Linux it is inefficient.

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 with fixing the problem.

It slows down in both Firefox and Google Chrome, so it doesn't seem like a browser problem.

I tested my site with Firebug and page speed expansion, so I decided to try it on GamesByEmail. Results are displayed in ShowSlow . This is actually pretty fast in terms of conventional web development - it just gets broken on Linux.

Please, can you, with all experienced Linux developers, test the game and give us some tips?

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

Answer 1

@Hogan and @CasualCoder, there have been several discussions in the return channels just like you mention: this performance suffers as the game progresses due to the large images used for color overlays. The game uses:

• 129 Select images (fill in the area with the mouse)
• 92 Color overlays (shows which player owns the territory)
• 129 IMG-tags for the "Pulse" effect (repetition of images with 129 hitility).

= 350 IMG tags.

At the beginning of the game, 92 color overlays represent 1x1 pixel images. Highlights: 1 image per area, mostly transparent, corresponding to the size of the board, but usually only 1 is visible.

As the game progresses, the overlaid images are replaced by images that show one territory in red or blue, etc., depending on which player owns it. These colored overlays are the same size as the board, although mostly transparent. At the time, we believed that these images would render as fast as images with less clipping (and this is similar to some of the older IE browsers in windows).

But, based on some other test results, I got there, it seems, a lot of support that these 947x622 pads are a problem; combined with which of the main images are also visible.

This is the worst case for 92 visible IMGs for conquered territories, plus maybe a dozen or so impulse IMGs for current empirical images - 105 947x622 (boardize). It is troubling that this leads to extreme slowdowns when moving the mouse in Linux and Mac browsers.

I edited my gimp scripts to instead generate glare and overlays as tightly cropped as possible, and output the offset X and Y data into a text file (which I then inserted into the code and used to place new images relative to the top level, left corner of the board) .

The new implementation seems to work better in my dev environment (I hope I'm not too faked by the local host here). As soon as I can get it online and test a few more, I will update the comment here.

Thanks again for the feedback, I hope the new cropped graphics will solve the problem.

Troy

Edit: The latest edited image code for Empires is now online. Just expecting more general feedback, but so far it seems like it feels much more responsive in both Windows FF and Ubuntu FF! Thanks again for helping everyone :)

Answer 2

I'm the guy who wrote the “awful design” called “Empires”: O

At first, I knew that it would be a lot of logic, but I had no idea what I was drawn into.
In the end, knowing that there are performance issues (for example, on Mac and Linux), I thought it was best for me to at least make it available for the game, fix it as best as possible and get it there so that I and some friends can play the game.

It turns out that as the game approaches the success of Epoch 7 it turns out pretty badly. (so many pieces on the board). Iain, ealier, when I mentioned, there were too many DOM elements, these were many images that I talked about.

The main developer behind gamesbyemail.com (who makes awesome games and doesn't let Empires fool you with the quality of his games!), He mentioned that the performance difference between a small gif and a board is the size of the gif, which is mostly transparent.

The problem is that the attempt to clone HoTW-2001 led to the use of a large number of images.

There are some optimizations that I am ready to go here, but did not manage to finish. (It will take me about 12 hours to test everything before the release, and even then it is easy for errors :( But I have plans:

• Eliminate all the pngs (if I don’t have yet ... there is a variable that switches between gif or png. I really like the transparency of png, but this extra channel doubles the image size :(
• Turn off the impulse effect.
  I wanted this to help define the "current empire," rather than the "previous empires" owned by the same player. The problem is that animation is simply expensive for many browsers :( (I know, I probably should use flash or the canvas tag, but the Scott API is so painfully rich and strong ... too much to implement it myself).

So, I ... I just need to get off my butt and put it on, at least above.

Troy

PS. Another URL for testing the game may be to view the game here . You can play the whole game like all players.

Answer 3

Google Page Speed ​​tests how well a site follows best practices, and not how well it works. If the site is sluggish in Chrome, try the Google Speed ​​Tracer , which will display what the browser does on the site. Compare its output between windows and linux.

Answer 4

just some additional feedback: the game seems incredibly slow on Mac OS X Firefox, too - I had to restart the "fox after it froze." Oh!

Answer 5

Another idea.

The original API is more suitable for games that use flat territories (for example, Gambit and WWII). Thus, instead of generating thousands of gifs that contain spotted shading (makes for a larger image), I also:

• Go back to pngs, use one color, for example: blue, but with a transparency of 30% and let the bottom panel provide shading and texture. OR
• Use gif, one flat color, without shading, and use the DOM properties to render it translucent (this has already been done in some places using several different browser-specific properties). The only challenge will be to look good visually.

A possible advantage here is to reduce the size of the transmitted data per image request. However, it still leaves a problem with a lot of queries.

Finally, it is possible to combine this approach with the approach to writing, and instead of displaying thousands of individual images from the main map (gimp image), I visualize the territories with one gigantic image (with an additional transparent space around each territory).

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

Troy

Answer 6

change

Ok, this is a terrible design. It loads tons of gifs (2 for each area), the size of the playing field (947x622) and overlays them. Then on the mouse above him switch two. In any case, I expect this to be the cause of poor performance.

Did it help? Now that you know how it was implemented poorly, what is it really important for? Just play in the windows.

original post Well, something works fast on windows, and slow in linux means nothing. You can run it on an 8 GB quad core with a huge drive for Windows and a netbook for Linux. This will slow down the work. So tell us ... what are the technical differences between the two machines. I assume that the Linux machine has less memory, and this application likes a lot of memory for java and graphics.

Answer 7

Today I am profiling. Here is sample data from Epoch 7 save game I have here. Pretty close to the worst case scenario, and, with an impulse, so I'm starting to think, maybe I can get away from the throbbing, 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 see indicates that it is always eaten inside mouseMove and its subfunds. Determining which territory the mouse is located in is usually O (n). Iterating through each polygon of each territory until we find one containing the mouse X, Y. (things like "normal ()" are part of this process. It also uses bounding fields, so there is some optimization).

But I don’t understand how this performance can become much worse at the end of the game (with a large number of overlay territory) compared to the beginning of the game with a very small number of overlay territory. Searching the territories to determine which one the mouse is in may not be a problem ... but some kind of side effect that arises from this, OR that the browsers on Linux and Mac are overloaded with the volume of DOM elements created with so many small images on the screen (?)

Viewing images on the screen:

• maybe 120 images for color areas.
• another 130 or so for the allotted territories.
• "pieces.gif" to show monuments, cities and army guys, another 240+ of them

This is only about 500 gifs on the screen at a time, or 250gifs and 1 gif sprited 240 times

This suggests that I myself from the base API do something really expensive when there is a color overlay on the territory. (because at the dawn of history, performance is pretty good when the mouse is around the board).

Maybe I need to view all the code inside the territory .updateHtml (); (who said this was not a question of code? ... ha! I don’t think he saw 15,000 lines of spambet javascript madness that I wrote: o).

Maybe I need to run a similar profile run from Epoch 1 to see how it looks? I will send a message if I find out more.

Troy